Computer terminal

Digging into git commands for deployment

In the first part of this tutorial, we discussed a mental model of deployment stages mapped to git branches. We also discussed conceptually how running a git push origin branch-name to push code to the remote repository can trigger a webhook which we can use to pull code from the repository to a server using git pull origin branch-name.

In the second part, we setup our servers, repositories and deploy keys. Our servers can now run git commands to pull code from the remote git repositories.

In this part, we dig into git commands that we’re going to use for pulling the code.

git pull

The simplest command and one that we use frequently is git pull origin branch-name. This pulls the latest code at that particular branch. Along with it, it pulls the whole commit history till the latest commit. Which means that there’ll be whole lot of data that your server doesn’t require.

You may need the whole scm data that comes in the .git directory. If that is the case, you can use git pull. However, if you’re like me, you don’t want to maintain the whole repository on these servers. I’m only interested in the latest code, not the code history.

git archive

With the right parameters, git archive will take a particular branch (or another ref, like a tag) and archive all the code in it (in a tarball), without the scm data (or the .git directory). You can test this by running the following command combination inside any local repository of yours:

on any of your local repositories. This should copy all the files from the branch-name branch into the /path/to/directory by creating a tarball and then unpacking it there.

We can also run this on a remote repository instead of a local one. To test that in the same local repository, run the following command:

When working inside your local repository, you can use the --remote=origin flag. This means that the git repository will have to be initialised and a remote by the name of origin added previously.

The best part, however, is that you don’t have to be inside a local repository. You could be anywhere and instead of a named remote, you could directly pass the git url as remote:

Nice command, only GitHub doesn’t support it. You can run this command on GitLab and BitBucket but not on GitHub.

svn export

Fortunately, there’s a workaround, if you are interested in slim deploys without the scm data. GitHub supports SVN clients. The master branch maps to the trunk of svn and other branches are accessible as branches/branch-name.

The svn export command is similar to git archive and the following command will do exactly what our git archive command above would have done:

for the master branch and for any other branch:

Maintaining git repositories on the server

Even if you choose to maintain the whole repository, maybe because you don’t wish to use svn and your repository is on GitHub or for any other reason, you should be a little careful about where your local repository is maintained.

For eg, for your theme, you could maintain your repository in the

However, if someone manually uploads the theme zip file, your deployment process would break because the .git directory will get deleted and there’d be no scm data to work with.

A workaround is to maintain the repository in a different directory, say

and after running git pull, you could run a git archive to move the latest code to the actual theme folder.

In terms of git, if all the directories are created, your process would be as follows to set up the deploy:


Then when you you need to run the deploy

Now that we know the commands that we need to run, let’s set them up in the next part for an automated deployment!

What do you think?