Git For Web Programming #1
Git is a powerful version control tool, so powerful, even more so than with subversion, you yourself define the strategy that you use to employ it’s features. There are myraid ways of doing things and what’s best really depends on what you are doing. In my opinion two of the most important features of git are the ability to easily track incremental commits during development without breaking the entire build for all users and it’s support for sharing commits between branches. Both of these features solve major problems with subversion, in which there is no way to commit changes that aren’t ready for primetime while still retaining a readable revision history in the repository.
Beyond these features though, I have found a few capabilities within git that are ideally suited to web programming. One is the use of the rebase option to update live sites while keeping those sites on version control. Often, once a site is live either the installation environment or extensive use will uncover latent bugs in the build. Sometimes it’s quickest to just fix these on the live site, and move them back into the repository trunk from there. If the site is not on version control, copying of files is the only option, thereby losing detailed commit history. On the other hand, a live site has different database and server settings, sometimes intermixed in settings file that have configurations that are global to both development and live installations. Git rebase can be used to solve this in a slick way.
Consider the trunk branch on my development server
r1 - r2 - r3 -r4
where r4 is the latest commit. We got live by issuing git clone on the live server, where we now have the same revision history. However we need to update settings for the live server (or staging, or whatever else). So we issue
git branch production
git checkout production
At this point we are on the production branch, so make our changes and commit. All is well and the site is live. The production branch contains the following revision history
p1
/
r1 - r2 - r3 -r4
However we continue development, so now the trunk is
r1 - r2 - r3 -r4 -r5 -r6 -r7
We want go live with the changes, but we don’t want to take the site down even for a minute. Anyone who has used git a little will know that the rebase command allows for an easy way to create the revision history
p1
/
r1 - r2 - r3 - r4 - r5 - r6 - r7
The key here tho, is not to rebase the live installation off of the branch ‘master’ as you normally would, but instead to rebase off of ‘origin master’. Normally you would rebase by first switching to the master branch (git checkout master), pulling down changes (git pull), moving back to production (git checkout production) and then rebasing (git rebase master). However for the live site this would mean going offline. A much better option is to never leave the production branch and simply issue
git pull
git rebase origin master
This will rebase the production branch off of the remote tracking branch pulled down by the fetch, and keep local changes on the tip of the branch. Git is very fast, and the rebase takes place in the blink of an eye normally. Of course it’s always a good idea to take your site offline when you update, but since a lot of folks updating sites are doing so by ftp or rsync while the site is live, this is by far a better option. All of the updated changes are stored on the live server in the remote tracking branch and need only to have their changes copied over into the checked out copy which is viewable by users. This is also much safer since a network failure has 0 possibility of leaving the live site in a confusing in-between state.