Git workflow for web development
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.
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
push without specifying the branch:
[branch "master"] remote = origin merge = refs/heads/master
General “one time” steps to setup remote server
.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:
Git repos on remote server
Create your bare repository
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://firstname.lastname@example.org/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
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):
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
#!/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).
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!