Git Ist Schnell!

I wanted to follow up on the WhyGitIsBetterThanX project that I basically stopped working on the day it went live and am now spending a few minutes a day maintaining.

Basically what happened almost as soon as the website went live is that people saw that the source was on GitHub and began forking it to translate it. Thanks to these unsolicited volunteer translators, we currently have seven translations in addition to English –
German,
Spanish,
French,
Italian,
Portuguese,
Swedish (partial) and
Traditional Chinese.

There are a couple of interesting lessons here. First off – the branching model in Git is very good for keeping translations of things. How the process basically works is that someone will fork my master branch (English version) and translate it and send a pull request to me. Then I’ll review it, create a branch name (ie: ‘de’ for German) fetch their remotes (‘gh network fetch’) and merge their branch in. Then I add the subdomain to my webserver, edit the upload script in that branch to upload to that directory and we’re done. It takes about 5 minutes to setup a new domain.

This is the cool part. People will fork and change the main English site (fix spelin errs, or grammar or make it XHTML valid, say…) and push that and send me a pull request for that. Then I’ll merge that in and push out an update for the main site. Then the translators will often merge that back into their translated branch, resolve any conflicts and send me another pull request, which I can often just fast forward.

This means that I’m able to maintain a pretty fair amount of patch work not only on my main site, but on all 8 branches simultaneously and it literally takes me maybe a few minutes each morning. Git, GitHub and the github gem make this process so easy I feel sadness for people who have to actually accept patchfiles still. There is absolutely no way I would do this if I had to download patchfiles from email or had to deal with 8 directories (which is how you would have to do it in bzr or hg).

I put the site live December 1 and in the 4 days since then I’ve merged in about 120 change-sets from 23 different contributors to 8 separately maintained branches without ever getting confused and without ever spending more than maybe 10 or 15 minutes a day on it. Once again, those numbers are :

• 4 days
• 120 patches
• 23 contributors
• 8 separate branches
• 10 minutes a day
• 0 problems

If you are the maintainer for a project, I would highly recommend thinking about changing your patch-submission workflow to forks on GitHub (and not just because I work here).

Written by

Scott Chacon

@schacon