A Really $h!t Branching Policy

“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.






  1. Martin Eigenbrodt (@Eigenbrodtm) · November 1, 2012

    > Use a source control system that maintains branch history.
    I love git. But not keeping book of branches and tags sometimes really hurts. Any suggesstions for a decent VCS?

  2. Andrew · November 1, 2012

    Recently a product team sent me a proposal that broke the build process out into no less than 15 different branches that would all have to get merged back into one branch just before the product ship date. The justification is that it would, “simplify the process”

    Still trying to understand how that works…

    • jamesbetteley · January 22, 2013

      Haha! That’s a good one. Someone else suggested a “branch per developer” which all merge back to a single branch (presumably at the most inconvenient moment). I love these branching anti-patterns!

      • Mark · September 26, 2014

        Sounds like the typical DVCS pattern tbh.

  3. SutoCom · November 2, 2012

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s