DevOps Zone is brought to you in partnership with:

By day I'm a build and release engineer in London, but by night I'm a normal person! If anyone ever asks me what I do, I usually generarlise and say "I'm in I.T." and then check to see if they've already stopped listening. When I'm not working or blogging I can be found playing rugby or cycling around the countryside on my bike, in an attempt to keep fit and fool myself into thinking I'm still young. James is a DZone MVB and is not an employee of DZone and has posted 54 posts at DZone. You can read more from them at their website. View Full User Profile

A Really $h!t Branching Policy

  • submit to reddit
“As a topic of conversation, I find branching policies to be very interesting”, “Branching is great fun!”, “I wish we could do more branching” are just some of the comments on branching that you will never hear. And with good reason, because branching is boring. Merging is also boring. None of this stuff is fun. But for some strange reason, I still see the occasional branching policy which involves using the largest number of branches you can possibly justify, and of course the most random, highly complex merging process you can think of.

Here’s an example of a really $h!t branching policy:

Look how hateful it is!! I imagine this is the kind of conversation that leads to this sort of branching policy:

“Right, let’s just work on main and then take a release branch when we’re nearly ready to release”

“Waaaaait a second there… that sounds too easy. A better idea would be to have a branch for every environment, maybe one for each developer as well, and we should merge only at the most inconvenient time, and when we’ve merged to the production branch we should make a build and deploy it straight to Live, safe in the knowledge that the huge merge we just did went perfectly and couldn’t possibly have resulted in any integration issues”

“Er, what?”

“You see! Its complexity is beautiful”


Branching is boring. Merging is dull and risky. Don’t have more branches than you need. Work on main, take a branch at the latest possible time, release from there and merge daily. Don’t start conversations about branching with girls you’re trying to impress. Don’t talk about branches as if they have personalities, that’s just weird. Use a source control system that maintains branch history. Floss regularly. Stretch after exercise.

Published at DZone with permission of James Betteley, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


darryl west replied on Thu, 2012/11/08 - 4:09pm

branch late +1.  merge daily +1.  stretch after exercise? -1.

Loren Kratzke replied on Mon, 2012/11/12 - 2:44pm

 Take it one step farther. Don't even branch for a release, simply tag it. Branch from the tag later if necessary for a bug fix release. But branching implies that you will be committing which is not the case if you are releasing.

Thomas Michaud replied on Wed, 2012/11/14 - 6:14am

Scratching head.  I'm from the SVN days where a branch and a tag were essentially the same thing. 

So tag, branch, shrug.  No big deal.   I was going to argue for more branching...right until I saw.... MERGE with...

WTF?  Why merge at all?  If you tag/branch, you're indicating the code to go with.  Why merge at that point?

Adrian Wilkins replied on Wed, 2012/11/14 - 10:39am

This sounds like a throwback to the SVN days (ok, SVN is still very popular in certain circles) ; SVN branches easily, but merging is horrible.

The solution is to branch for EVERYTHING. "But, that's insane!" you say... well, how come it works just fine for the Linux kernel and many other projects?

1) Use a version control system that merges properly. You're basically talking Git, Mercurial, or Bazaar. Subversion has made some effort in this area - but too little, too late.

2) Branch for everything. You should branch for each and every change you make to the code that could be considered a single functional unit. Have a bug in your release? Branch the tip of your release branch to fix it. Have a feature you want to mess around with? Make a branch for it.

3) Here's the key part - don't let branches fester around and get out of date

* Merge outward from trunk often - SVN making this hard was the main reason that everyone hates merging, which is the reason they don't do it.. which means they leave it too long, and it get's to be a big job... which is the reason they hate merging... which is the reason they leave it too long, etc. Repeated small merges in modern DVCS systems are easy. Remember kids - when you all develop on /trunk - this is what you are doing anyway. Every time you update, you're merging other peoples commits to your code. Every time you start working again, you are implicitly creating a new branch (that has one revision - your local working tree). But when you do it on feature branches, a) you control when the merging gets done instead of hitting update and praying to C'thulu b) Your commits aren't mixed in with a bunch of other commits that have nothing to do with yours.

* Review code for merging to trunk. When your feature is "done", tell the guy who is reviewing your code about your branch and push it where it can be seen. You do have code review, right? There are lots of tools like Gerrit that facilitate this process and also help with the code review. The tip of your branch should build, and pass any automated tests you have going. When it get's approved, merge it. You might want to merge it more than one place - if it's a hotfix for a deployed release branch, you'll also want to merge it into the main development line if applicable.

4) Reap the benefits

Now your main development line only consists of review commits that implement a single feature or bugfix each. Every revision should build. Every revision should have a decent log comment. Finding out which commit broke something should be easy as pie.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.