Using Git Branches as Patches

At Viddler, we’re now using Git for projects, and it’s going really well so far. While we haven’t figured out the perfect workflow just yet, we’re doing some things I really like, and one of them is treating branches like patches.

Often, people think of Git branches as a full copy of the parent branch, but it’s better to treat them as a simple collection of new commits, to be applied to the parent branch later. This might not seem too revolutionary, but this small change in thinking can really improve your workflow.

For example, at Viddler we use Trac to manage tickets, and in Git. For each ticket in Trac, we create a branch, called something like 3241-fix-embed-codes. We have two permanent branches: dev, which reflects current development, and master, which is considered always production-ready. So, dev and master are going to have different code to reflect their reflective stability. To get started with a fix, we first create a feature branch from master:

git checkout -b 3241-fix-embed-codes master

This simply creates a new branch of master called 3241-fix-embed-codes and checks it out. When the ticket is completed and the code has been committed, the patch thinking really comes into play. Since this now needs to be tested in the dev environment, the branch first gets applied to the dev branch:

git checkout dev
git merge —no-ff 3241-fix-embed-codes

Using the —no-ff option on git merge is important for this patch mindset: it creates a separate commit for the merge itself, which allows you to git revert the entire thing (if necessary), rather than having to undo each individual commit within it.

Once we’ve decided this fix is read for production, it’s time to move the code over to master. Without the patch mindset, you might consider merging dev into master, but that means you’d be copying anything that’s applied to dev, some of which might not yet be ready. When you think of your feature branch as a patch, however, it’s easy to only apply the one you need. To apply this patch to master, just use a similar method as before:

git checkout master
git merge --no-ff 3241-fix-embed-codes

Now you’ve only moved the safe commits over, leaving any buggy code safely in dev.

This method may seem obvious, but the mindset has really changed the way I use Git, and I think it makes it a much more powerful tool, especially when you’re working across multiple environments (like production and staging). I’ve skipped over some additional considerations, like merging master/dev into your feature branch, but those are topics for a future post.

Posted on May 6, 2010 • 2 Comments
Tagged with: Git, Workflow, Source Control, Branching, How To