Your branching strategy should mirror your reality

People have their religions about the “right” way to do branching. Unfortunately, the real world is rarely that simple.

There is the “always develop on master” tribe, who attest that branches are evil and anything other than working on master means you aren’t doing continuous integration, which makes you evil.

There is the “do all your work on branches” tribe, who attest that each developer should create a new branch for each piece of work and merge it back when the piece of work is complete, possibly via a pull request (because code review).

There is the “branch per environment” tribe, who feel that it’s easier to manage the flow of parallel and independent development streams throughout their pipeline if each environment is versioned independently.

There is the “branch per release” tribe, who value the ability to have some of the team test and refine the current release while the rest of the team are working on the next piece of work.

There is the “GitFlow” tribe, who believe that GitFlow, while more complicated than some other strategies, is a standard that provides support for most use cases while also providing a common branching process that everyone can understand.

There is the distributed (Git) tribe who value the flexibility that comes with a distributed source control system and their superior support for frequent branching.

There is the centralised (TFSVC) tribe who like… unnecessary self-inflicted pain. (Perhaps I’m guilty of having my own opinions too?)

Leave your branching religion at the door

Fortunately, most religions promote similar practices: Don’t kill people, don’t commit adultery and, whatever you do, don’t spend a year working on a branch before you merge. Hopefully we all have some common ground. That said, I propose that next time your team comes together to agree on a branching strategy you agree to leave the details of your branching religion at the door.

In most teams there will be team members who belong to different tribes and they are never going to agree on the “right” branching religion no matter how angry you get and no matter how wrong they are. Please don’t hijack that discussion with ivory towers, pearly gates and unicorns. If other team members belong to a different tribe, that doesn’t make them blasphemous to your branching Gods. And if you lose your temper with them because their branching religion is different from yours that makes you an arse.

Here’s a strategy for employing a bit of empiricism into your branching strategy: Map out your reality.

The rule for mapping out your “reality branches” is to draw out all the different versions of your code. Versions of your code only match if they are exactly in sync. Further ahead or behind along the same timeline is fine, but if there is an instance of your code where the ones and zeros are not exactly identical to any point in the history of master that counts as a “reality branch”. That goes for code on developer machines, test environments, production environments and in any other place.

If you have different teams working on different features at the same time, that’s a different “reality feature branch”.

If you have people making production hot-fixes (I know it’s controversial, but it happens – let’s not make it a sin that we are afraid to talk about) that’s a different “reality hot-fix branch” too.

If you release different features to different environments independently at different times, well, by our definition, that’s another “reality branch” because at no point in the history of master was there a version with features A, B an E but without C and D (which were still in dev).

That hobby project you are working on but not in the main team repo – well that’s another “reality branch” now isn’t it. And all that unused test code still hanging around in the test database? Well, that probably means the test database is on its own special little “reality branch”.

You deploy your code to 50 customers, each with their own tweaks and customisations… I hope your religion promotes forgiveness.

Once you have figured it all out take a step back. Well done. Have a biscuit and admire your work.

Take that in for a second.

Isn’t it beautiful?

You’ve mapped out the reality of your existing branching strategy with all of it’s sins and disfunctions. You may as well use the features of your source control system that help you to codify your reality. After all, if your source control branches do not match your reality then the process won’t make sense and people will break the rules.

But wait… what’s that you say? Your “reality branches” don’t match the commandments of your given branching religion? Not even the fundamental shared principles that even your complex, multi-faith team can agree on? The scribbles and squiggles on that whiteboard represent a crazy branching strategy by any modern standard! Are you seriously asking me to follow THAT branching strategy in source control!? That bowl of tangled spaghetti! What must I be smoking?

Well – perhaps if your “reality branches” are in such a mess, your source control branches aren’t the problem after all?

*

This blog post was inspired by various conversations with various companies in the last few months. With each company I was delivering a DLM Health Check. (The company mentioned at that link was not one of those companies.) Each of the companies in question took something valuable from this approach to resolving theological source control wars.

*

Image source.

Leave a Reply

Your email address will not be published. Required fields are marked *