Deploying with Git

Git, a powerful version tracker, is easily becoming one of my essential software tools. I now use it on every creative project at home and increasingly at work too.

But you might say “I get versioning automatically with Time Machine or Dropbox”. Sure and that’s nice but when you consciously manage versions yourself you can track simultaneous changes across multiple files and you get comments on each version to help you know what changed when. You might say “I already have decent version tracking at work with Subversion/Perforce/CVS”. Well you can still get a great benefit by running Git locally — think of it as a layer of private versioning on top of the shared, published repository.

Although Git’s known as an SCM, or source code manager, Git is also useful for non-coding projects such as graphic art, music, spreadsheets or word processing — things built using tools that typically have no native version management (other than undo and save as). Initializing a new Git repository takes only a couple seconds (!) and tearing one down is just as quick (“rm -rf .git”).

So, deploying?

Okay, we’ve established that Git is awesome but one of my favorite uses of Git is to utilize its distributed nature to maintain and deploy website files. Before I get into the techie details on setting this up, let me explain the benefits of this technique.

Typically, website files exist on a local machine (e.g., laptop) and on a server (e.g., your hosting provider) and one would edit changes locally and then (testing locally is optional) FTP the files to the server. This process is error prone — for example you might forget to transfer one of the files or, even worse, make emergency changes on the server and never make the change locally and later overwrite those server changes, losing them forever.

By using Git and the technique outlined below, you will still have two copies of the files but the synchronization is much simpler. Primary benefits include:

You deploy the site by simply typing git push on the local box (or through a visual tool, more on those at the end)

Edits made on the remote host can be synchronized locally via git pull

After a bad push, roll back by running git reset –hard ORIG_HEAD on the remote host

Oh yeah, if they weren’t already, all your website files are now version controlled. Awesome!

How to set your site up with Git

First, if they aren’t already, stick your local website files are in a Git repository.

Then, FTP (or scp) the hidden “.git” directory that was created by those commands to the server in the corresponding location in your files (assuming they’re already on the remote host — otherwise send everything over including “.git”).

Next, add the remote host config to the local repository:

git remote add prod ssh://user@example.com/path/to/site

Now, to make a push result in updated files on the remote host (as opposed to only an updated repository record) replace the remote’s .git/hooks/post-update file with a copy of the hook script linked to in this FAQ entry.

Then, to eliminate a warning that Git spits out add the following to the server side .git/config:

[receive]
denyCurrentBranch = ignore

An optional but recommended step is to set up passwordless SSH to make things super fast and clean. It is also strongly recommended to ensure your server’s .git directory is not allowed to be viewed by anyone browsing your site (see htaccess or the equivalent for your webserver). Also you will want to configure the local repo’s default remote so that you can run “git push” or “git pull” without specifying any other parameters:

[branch "master"]
remote = prod
merge = refs/heads/master

Git Tools

If you’re on a Mac and you use TextMate, there is a decent Git bundle that you can add in. (I don’t love the flow but it works.) Also, GitX is a nice graphical UI for Git on OS X. On Windows I’ve enjoyed using Git Extensions. And lastly, here is a nice Git cheat sheet with some more advanced stuff in it.