For how important branching strategies are, we don’t talk about them as often as we should. We pick our approach, alongside the core languages and tools, at the start of a project and then never think about it again. At most, we might make minor tweaks around the edges — how many reviewers need to approve a pull request, what git tags we use, when our pipelines are triggered, etc. But we rarely check whether Trunk-Based Development or Feature Branching is still working for us.
Software development is not static. Our teams, projects, and the approaches we take are constantly evolving and changing, and failing to update our branching strategy in response results in a lot of pain for the development team. Neither branching strategy is inherently better than the other; each has different circumstances where it shines. Multiple times in my career, I have found myself part of teams locked into one particular strategy when the other would have been a significantly better fit for their situation.
The impact our branching strategy has on the development team shouldn’t come as a surprise. After all, our branching strategy is the primary method we use to communicate and collaborate with other developers. Broadly, the problems we see with branching strategies fall into three categories: the strategy is not a good fit for the team or project, is not implemented well, or lacks developer buy-in. Below, I will cover situations where each strategy is strongest, cover issues you might have with your current implementation, and then provide guidance on when and where to use each.
An overview of branching strategies
All branching strategies fall into one of two categories — Trunk-Based Development or Feature Branching; everything else is just additional process layered on top of these two core philosophies. The primary difference between Trunk-Based Development and Feature Branching is how frequently developers commit or merge into the main branch. In Trunk-Based Development, we prioritize having all developers working against the same version of the codebase. The development team regularly pushes changes to achieve this, trusting in high test automation to keep the main branch in a good state.