Git workflow for web development

Sunday, August 23rd, 2009

First off, I should point out that this is not a Git tutorial. If that’s what you’re looking for, I can’t recommend enough the PeepCode Git Screencast. You’ll be up and running in a couple of hours.

This article is more of bullet point type step-by-step on how to integrate Git within your web development workflow. The basic idea is to have a bare repository hosted remotely that serves as a “hub” you clone from. First you start working locally; when you got some work done, you create the bare repo on the remote server and push all your local work there; when you’re ready to let your client review it, you clone the bare repo one more time to a protected directory only your client has access to. Ideally you’d also want the live site to be a Git clone, but often enough clients already have their own hosting and it’s not always practical.

I have a life account with joyent from back in the days when it was TextDrive, so that’s where I host my Git stuff. Some of the details below are pertinent to their specific setup, but most of it should be relevant regardless of where you’re hosting your stuff.

Local

Create the local repository:

cd ~/Sites/client-name/site-name
git init
$ git add .
git commit -m "initial import"

Add this to your local Git config file (inside the .git folder) so you can use pull and push without specifying the branch:

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

Remote

General “one time” steps to setup remote server

Hide .git/ directory from privy eyes via .htaccess:

RewriteEngine On
RewriteRule ^.git - [F,L]

To exclude files from Git globally, use this command to setup the Git config file:

git config --global core.excludesfile ~/.gitignore 

Then create a .gitignore file in ~/ where you can list files to be ignored, for example:

.htaccess
htusers

Git repos on remote server

Create your bare repository site-name in ~/git/client-name/:

mkdir -p git/client-name/site-name
cd git/client-name/site-name
git --bare init

Push the work you’ve done so far from local repo to remote “hub” (if you’re using Joyent and get an error there, there’s a fix explained further below):

git remote add origin ssh://[email protected]/users/home/username/git/client-name/site-name
git push origin master

Clone your bare repo to the “live” directory you’ll direct your client to:

git clone ~/git/client-name/site-name ~/web/public/subdomain

Hooks

To setup a hook to push changes directly performed on the live server (for those last minute minor tweaks) to the bare repo, go into the live site’s Git repo hook folder, and add this to the post-commit hook (make sure the file’s permissions is executable (755) with something like chmod +x hooks/post-commit):

git push

Pass Protect your directpries

To pass protect the directory your client will access via HTTP with webmin, go to: Virtualmin > Services > Protected Directories > Edit Mail and FTP Users (this is for webmin, but cPanel, Plesk, etc… all have a way of doing the same thing).

For Joyent users

A couple of Joyent’s hosting specific settings (and maybe other Solaris setups in general, I don’t know). You need to change the shebang in the commit-msg hook (in “live” repo) from #!/bin/sh to #!/usr/bin/bash and also, if you get an error that says something like “hooks/update: syntax error at line 40: allowunannotated=$ unexpected” you should “turn off” the hooks (in the “hub” bare repo), setting them to 644 with something like chmod -x ~/git/*/hooks/* (thank Andy for the fix).

Conclusion

That’s it! You can now push, pull, and commit as much as you want from your local dev server to your “hub” and pull the changes on the remote “live” clone when you’re ready to let your client see the changes. And when your client needs a quick edit directly on the live server, it gets pushed automatically to the bare repo so it’s really smooth to stay in synch locally.

It’s a little bit of work to setup, but once it’s done. You’ve got yourself a smooth workflow with all that Git has to offer built right in. Once you go passed the initial learning curve, you’ll love it. Guarantied!

Filed under: Web Design, Workflow