Geek on Two Wheels

In any sane web development setup, at some point, content must be propagated from the development environment to the production one. scp and sftp are some of the favourites: git is mine.

By using the working directory of a git repository as your live website, you gain several notable advantages over manual uploading:

• The website itself doubles as your primary, authoritative repository.
• It becomes possible to apply all of git’s features on your production website. Things such as emergency roll-backs become trivial, dependencies permitting.
• No need to think about what actually needs to be uploaded and what doesn’t on an update: just git push.

Now, the last point needs some explanation. When blobs are pushed from one repository to another, by default, the working directory of the remote repository is untouched.  The reasons for this should be obvious, but, in this case, modifying the working directory is precisely the desired behaviour.  To have git update the working directory every time it receives an update, we use the post-update hook.  Here is a trivial example:

#!/bin/sh
# Update from repo
cd ..
unset GIT_DIR
exec git reset --hard

1. git runs its hooks from inside the .git directory. Not all git commands work from this location, so first we get out from it.
2. The GIT_DIR environment variable is set to “.” when executing hooks. This will cause issues as we are no longer in .git, and must be unset.
3. Finally, git reset --hard is ran to reset the working directory to match the current branch’s data in the repository.

Of course, there are tons more things you can do using the hook, as you have full shell scripting capabilities.  See git help hooks for information on all the available hooks.

As a departing note, remember to set the permission on the .git directory so that you are not leaking sensitive information.  Unless, of course, you want everybody and anybody to be able to checkout the complete revision history of your website.