DevOps: To branch or not to branch
One of the discussions that comes up from time to time when working with DevOps is branching strategy.
Common strategy
The general strategy nowadays is to have a main branch (used to be called master) that is used for deployment. When features are being developed, a feature branch is forked from the main branch, the changes are built and tested, and then the feature branch is merged back to the main branch.
When to branch
One of the main features of Git that’s often claimed is that it’s so good at branching and merging. And indeed, it’s pretty good at that. But the bigger question is whether lots of branching is desirable in the first place.
One argument says that if you are using branches (let’s say to build features), that you really aren’t doing Continuous Integration (CI).
The downside of building features in separate branches is that at some point, you’ll have to merge the code back in, and there’s probably going to be nothing automated about that.
Where it can go wrong
I spend a lot of time in software houses. One large software house (over 500 developers) that I’ve been mentoring in has a very large number of active live branches. Each time a merge to a central trunk (ie: master branch) is attempted, it’s beyond painful, often takes months, and introduces enormous numbers of bugs that need to be fixed. If you then combine that scenario with a lack of good testing, you have a problem. Merging becomes really, really scary.
There is nothing agile or continuous about that.
A nasty approach
Another software house has one main branch, and has forked it off for each individual client. The development for each client is then done independently, and feature branches are taken from each of the client branches as needed.
This has many downsides. First, each client ends up having code implemented separately. As industry demands change, in many cases, they’re each having the same functionality implemented, but often in different ways. And each client pays for that.
Worse, they try to maintain a common main branch. Merges into that branch are renowned for taking forever. I remember watching a team of more than 12 people trying to merge client branch features into it. They gave up after a year. Within the company, it was widely regarded as a pointless branch, as no client was actually using it, and, most likely, no client could actually use it as it probably wasn’t really functional. Within the company, many people called it the latrine branch.
But should you avoid branches?
The alternative approach is to always work in the main (master) branch. While you can end up colliding with what other people are doing, the argument is that at least you deal with the issues right then and there. The problem is that you can end up with either a frustrating set of collisions, or you’re endlessly working with an unstable base. But, yes, at least you know about it straight away.
A related but bigger issue is that it’s easy to accidentally release unreleased features into the wild, or at least parts of them. Feature flags are often used to try to hide this but that can go wrong too. And the more you have, the messier everything can become.
So what to do?
So in the end, to work in branches or not? My take on it is that branches are fine if they are letting you try something out in a scratchpad area, and when they are really short-lived. They also work well for well-contained features but again only when they are relatively short-lived, and the code will be merged back in within a reasonable timeframe.
Long term branches aren’t something that I’m keen to see. Don’t let them get out of hand.
2026-11-11