The Most Natural Branching Model

This is about an argument I’ve had several times in my professional life as a software developer. To my mind the topic is pretty basic, no rocket science at all¹. It’s about branching in version control. And there’s plenty of articles and documentation out there discussing that basic topic and describing best practices.² So, I won’t make any claim that I could add essential new thoughts to it. But since that discussion keeps popping up every now and then I’ll write down my take on it and some observations and learnings just for later reference. And also because many of the results of a web search for “best branching strategy”³ are nothing but marketing filling material articles that try to be all too neutral or just mirror some ideas collected from their own web search. In their superficiality I haven’t found them helpful for decision making in a team. In contrast, this one’s gonna be opinionated and based on my own experience and learnings from the past decade.

TL;DR: GitFlow, though having gained notable popularity, came with substantial design flaws, but at least it made people come up with names for the nothing new but most natural branching model: The Cactus Model or Trunk-based Development.

Who needs parallel history?

So, you have heard about GitFlow. Sure, you have. It was very popular about ten years ago. And that was probably because it was very well thought-through and documented, really nicely presented in a well-written article, and first and foremost, it came with a set of clear rules. And people long for clear rules, especially tech people like us, don’t we? So, before I go into any criticism, I want to make clear that I really appreciate that model having been shared with the community. Making our ideas a common good instead of keeping them enclosed in the silos of our brains makes us move forward and grow together.

Anyway, here’s my bold statement: Alternate-history branches are bad 😱. If your branching model involves two or more permanent branches meant to be merged back and forth⁴ think twice whether it’s really worth the hassle.

Okay, it’s not like this kind of branching and merging is bad in the sense of killing kittens or inevitably ruining your team’s productivity. It’s just that it’s extra complexity added to your version control. And tech people like us want extra complexity to be be well-founded or avoided, don’t we? So, before settling on GitFlow or some derivative you should really ask yourself why you would want multiple branches telling parallel, divergent versions of code history⁵? At long sight, the only timeline that matters is the one documenting what changes were made to the main branch in which order.

Why complex branching doesn’t make sense

Now, before I go ahead and talk about the obvious alternative I want to point out what appear to be the core assumptions that led to the belief that multiple parallel branches are a good idea.

Branching ≠ Deployment

I often hear developers argue for two parallel branches because they want one for each deployment environment. The underlying common misconception seems to be that automated continuous deployment can only happen from a permanent branch that perfectly mirrors the deployment history. That’s not true.

To deploy a version-controlled codebase, essentially, you need a way to specify the commit that you intend to deploy at any time. While the most immediate way would be to just pass the respective commit hash to some deployment command, you’ll probably don’t want that as it doesn’t allow for automatic deployments triggered by plain commit events. What you’d rather want is some symbolic name on your version control that your CD can watch for. This is where branches come in handy, because branches are nothing but symbolic names for commits. Yes, it’s perfectly fine to rely on branches to point to the respective commits for your automatic deployments. But apart from acting as named pointers there’s nothing that branches do for you with regards to automatic deployment. Especially, there is no use in mirroring deployment history.⁶

No urge to merge

A common companion to the idea of having parallel branches to tell certain kinds of history is that those branches from time to time have to be “synchronized” by merging them. And not only those permanent ones but also all kinds of side branches, like feature branches, release branches, or hotfix branches.

While it’s obvious why you want to keep side branches up to date with the main branch, it’s quite questionable why everything happening on some side branch should need to go back into the main branch, even including the history of that side branch. My take on this is to be really relaxed about side branches and their history and only care about the main branch. As I said above this is where all relevant code history is written, whereas side branches only exist for one single temporary purpose and hence, are perfectly fine to stay open-ended or even be cut out, eventually. However, there should never the need arise to merge (as in, non fast-forward merge) them back into the main branch. Let’s prove this for the three common types of side branches mentioned above:

Feature branch

This is a branch owned by one developer (or small team) working on a specific feature. Its main purpose is to be able to implement that feature without getting distracted by concurrent changes to the codebase and without having to commit intermediary states to the the main branch. Only when the feature is ready all its related code changes go to the main branch at once. At that moment it doesn’t really matter⁷ when and on which base the original commits were made. If our goal is to keep the history free from irrelevant information then the cleanest way of merging a feature branch to the main branch is rebasing the latter onto the former and fast-forwarding the former to the rebased head (a. k. a. “rebase-merge”).⁸

Release branch

This branch is meant to point to a commit to be deployed to a given target or released as a package at a well-defined version. It’s not meant to receive any active development. The only changes that are acceptable as well as expectable on release branches are hotfixes. And those do not need to be merged back to the main branch. Instead they should be applied there independently. There are some best practices regarding a well-defined procedure for applying hotfixes by cherry-picking. But the important idea is that the main and the release branch are fixed by different commits (cherry-picks are actually less special than many people think).

Hotfix branch

This is either branched off of the main branch and then used for “a hotfix release”, making it effectively just a special case of release branch. Or it’s branched off of a release branch to work on a hotfix and then merge it back to that release branch. It all boils down to making hotfix commits to releases. Therefore the above also applies to this kind of side branch.

Keep It Linear, Lovely!

It might not always be true, but in this case K.I.L.L.⁹ is a special case of K.I.S.S.. As I pointed out above complex branching models are oftentimes less helpful than they were supposed to be. Instead, in most common cases it’s perfectly sufficient to stick with a much simpler branching model with just one main branch and only temporary side branches. While this idea has been nothing special for several decades it became the recommended alternative to GitFlow when people realized that the latter is rather getting in their way. It has since been referred to as Trunk-based Development with trunkbaseddevelopment.com having become the go-to information source.

I just love it for its simplicity and its similarity to nature¹⁰. Instead of having a Git graph full of merge commits we can just let it grow like a natural tree with one trunk and several branches that grow from it but never back.¹¹