Understanding the Git Workflow

Friday, 17 February 2012

I've used several version control systems over the years: SVN, Mercurial, Bazaar and even Perforce. (Shudder.) Usually I'd have to learn whatever system was already in place before I was brought into a project. For the most part I would only learn what was necessary to get work done with the tool. More recently though, I've been using and really digging into Git.

I came across Benjamin Sandofsky's article Understanding Git Workflow and it blew my mind a lil' bit:

In a perfect world, every change in your revision history is succinct and stable. There are no checkpoint commits that create line noise. There are no giant, 10,000 line commits. A clean history makes it easy to revert changes or cherry-pick them between branches. A clean history is easy to later inspect and analyze. However, maintaining a clean history would mean waiting to check in changes until they’re perfect.

[…]

Git is revolutionary because it gives you the best of both worlds. You can regularly check in changes while prototyping a solution but deliver a clean history when you’re finished. When this is your goal, Git's defaults make a lot more sense.

I was intrigued because he very accurately describes the Git workflow I use (and worse yet, the one I'm used to) and explains all its warts. He then explains the new-to-me intended workflow:

  1. Create a private branch off a public branch.
  2. Regularly commit your work to this private branch.
  3. Once your code is perfect, clean up its history.
  4. Merge the cleaned-up branch back into the public branch.

It's step 3 that I was missing. I guess coming from an SVN background, rewriting history seems a bit taboo to me. He shows some great, practical examples in the "Guidelines and Examples" section including how to use Git's powerful interactive rebase mode.