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.