Where I work we've switched our biggest project from Subversion revision control to Git. It is a large code base. I've been using Git for personal projects for awhile, but I've been keeping it pretty simple. For a large project with several contributors, Git is not only adequate, it's pure magic.

First of all, Git is fast. It's really, really, incredibly fast. On this particular code base, just running "svn status" could take 30 seconds. With Git, it never takes more than a second. Even "complex" actions, like merging large changesets, creating and merging branches take anywhere from 0 to 1 seconds. Really, you have to try it out to get a feel for how fast it is. Remember, this is a huge code base. The slowness of Subversion in comparison makes me think of the movie "Me and You and Everyone We Know." In it the foot store clerk, played by John Hawkes, tells the woman, played by Miranda July, when she tries to explain that her foot pain is due to her low ankles, "You think that you deserve that pain, but you don't." Eventually he tells her, "People think that foot pain is a fact of life, but life is actually better than that." If you think you have to wait for Subversion or whatever other source revision control because you have a large code base, you're wrong. You think that you deserve to wait, but you don't. People think that revision control system slowness is a fact of life, but life is actually better than that.

Branching is fast and relatively easy. First of all, everything happens locally. Git is really just a specialized database. Everything gets stored inside the single .git folder. You can create millions of branches with different changes and merge them every which way all without a functioning internet connection. If you have a central repository, just push your changes and pull other's changes at your leisure. So back to branching, I'm about to create a branch and switch to it. The branch I create will be a branch off of whatever branch I happen to be in. Hold your breath.

$ git checkout -b new_branch

Too easy? Just wait. Now let's assume that I changed some things and committed them to that branch, using "git commit". OK, now I want to switch back to the master branch.

$ git checkout master

Wait, that's it? What's in my working copy? The contents of the master branch, unchanged. The "new_branch" branch and it's change set are tucked away in that .git folder. You can then push that branch to the upstream repository like this:

$ git push origin new_branch

OK, so let's say someone wants to bring that branch into the master branch later. All they have to do is this:

$ git checkout master # make sure you are in the master branch
$ git pull origin new_branch # pulls in the branch to their repository
$ git merge new_branch # merges the changes into the master branch
$ git push origin master # pushes these changes to the master branch upstream

There are a lot of different workflows with Git. This is just assuming a "centralized" upstream repository. Even with the centralized model, there is a lot of flexibility. All of these operations are very, very fast.

With such prolific, easy branching, we now develop against reality not fantasy. With Subversion, we would just commit changes to the main branch, and our changesets would stack up on each other. Eventually, we had a backlog of changes that were all depending on each other, none of which had actually been merged into the production branch. It was a nightmare. Perhaps we could have had a better workflow with Subversion, but nothing seemed natural. With Git, the master branch is now in sync with the production site. We develop features against the site, as it exists, put them into a branch, and that branch gets merged with the master branch when the feature goes live.

We could have done something similar with Subversion but you have to merge changesets manually by revision number, and Subversion doesn't track these merges for you, so you have to be very careful not to reapply patches more than once. It's a big mess. Basically Subversion fails dramatically. Git. Just. Works.

One reason that Git does branch merging so much better is that branches aren't different folders with shared ancestry. Branches are just pointers to nodes in a directed acyclic graph of commits. Changes in one branch don't have to be recreated to be merged in another branch. Those changes have the same identification (a SHA1 hash), so they will not be applied twice. Here's a situation: you have three branches, A B and C. You make changes in all three branches. In branch A you merge in changes from branch B ("git merge B") and in branch C you merge in branch A, well you get branch B for free. If you try to merge in branch B into C at this point, Git already sees that each of the commits in that branch have already propagated to branch C, so nothing happens. That's what you want.

Commits are cheap, and have an identity. Every commit has a hashed id. If you want a single commit from a different branch, just cherry-pick it by id. If you merge that branch later, it already knows you've gotten that one part, so it won't re-add it. Smart, huh?

OK, Git isn't really magic. It's just computer science--which is nice. People in the subversion crowd are trying to keep it going, but I don't see the point. Continuing to use Subversion and other outdated revision control systems is masochism. Oh yeah, I've used a few others like CVS, Perforce, and Visual SourceSafe. Same crap, different name. If you haven't, do yourself a favor and try Git. Your whole life could be better. Just starting today.