How to Choose the Right Branching Strategy

Trunk-Based Development vs Feature Branching

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.

When to use Trunk-Based Development

When to use Feature Branching

The costs of poorly done Trunk-Based-Development

Trunk-Based Development’s most tangible benefit is reducing context-shifting and allowing the developers to focus on a single state of the application. The risk you take is an increase in distraction. Without a high level of test coverage and automation, you may be frequently disrupted by “broken builds.” These could be obvious changes that prevent the build from compiling, but more frequently are subtle changes in behavior or bugs that don’t get discovered until many commits later. Depending on the severity, you might find yourselves frequently downing tools to figure out who broke the build and who needs to fix it. Disruption from large and unexpected changes requires you to constantly adjust your code and mental models as changes come in. Feeling like you’re constantly working on an unstable foundation adds considerable stress and hinders your team’s ability to expand as more developers lead to more disruptions.

The costs of poorly done Featuring Branching

Ineffectively implemented, Feature Branching has its own costs. Branches frequently get stuck, spending a long time in development and then needing to pass through all of the sign-off gates on the way back to the main branch. These hurdles cause delays for all dependent work, and while ideally branching, features and tasks would be independent, in my experience, they rarely are. Attempting to prevent the developers from stepping on each other’s toes leads to the team working on too many long-lived simultaneous feature branches.

The problem of buy-in

For proponents of each approach, some of the above issues may seem unfairly attributed to the branching strategy. Rather than being problems with each strategy’s core, they’re problems with how it has been implemented and enacted by your team. If everyone were doing it properly, they would find that your favorite strategy would indeed be the best branching strategy.

Should you make the switch?

If you can’t apply one strategy correctly, you might switch only to find yourself with another failed implementation. There is a high cost to making a permanent change in strategy; developers need engagement, training, and guidance through the new patterns and mindsets. Significant changes will require manager approval and sign-off. You need to redesign and rebuild your build, test, and release processes and pipelines to favor your new strategy. You face months of discovering and resolving a variety of kinks and unexpected follow-on effects.

  • There is a high ratio of inexperienced to experienced developers, such as many new hires, juniors, or short-term contractors.
  • Manual testing is a requirement for keeping the main branch releasable.
  • The individuals or teams contributing to the code base are distributed across multiple time zones.
  • Frequent “broken builds” require the development team to down tools and investigate why the application is no longer working.
  • Changes occur across the application’s breadth, and different features and branches rarely touch the same area.
  • Teams have ownership over their own smaller projects and services.
  • A feature can go from “dev complete” to merged in less than half a day — any manual testing or sign-offs are either completed within that time frame or not required.
  • You frequently find yourself making branches off branches or integration branches.
  • The development team has to sneak changes into unrelated branches because they are too difficult to get in by themselves.
  • Most changes are concentrated within a relatively small area of the application.
  • Refactors have become discouraged due to their tendency to get stuck on a branch for so long that merging back in is difficult and risky.
  • Bottlenecks in your process are frequently causing branches to get stuck.
  • You have a rapidly changing project, are building a new project, or rewriting an existing project or component.

Senior Software Developer and occasional Scrum Master. Writing about the less technical parts of being a developer.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store