As David Boyle informed us in his blog Git and Revisionist Histories, here at Hymans Robertson we use Git for our source control, and as he also hinted at when you use git, if you don’t have a good branching strategy there may be troubles ahead.

At Hymans Robertson our development teams have a lot of independence, and one of the things that can differ (although in practice doesn’t that often) is our git branching strategy. My team recently chose to try Trunk-Based Development (TBD), an area of expertise of one of our colleagues.

The easiest way to approach Trunk-Based Development is to do so apophatically. Other strategies such as the popular Gitflow, involve the use of long-lived feature branches. Generally meaning features developed independently and merged back together. However, anyone who has tried performing these merges will soon tell you it can feel like creating some horrific chimera. Sometimes there is duplicated code, or code that works fine on its own but not in addition to other branches. Furthermore, branches for releases and fixes are generally used too, adding a lot of complexity to the process.

That’s what it’s not, but what actually is it?

Developers work on small branches, which are merged frequently (very frequently!) to a main or trunk branch. It sounds easy right? It kind of is, although this has some interesting properties, and advantages. One area of tension is that the trunk must always be release-ready, so shouldn’t include anything you don’t want to go live, be that broken code or partially completed features. This practice conflicts with small frequent check ins.

How do we deal with this?

The first is a continuous integration pipeline which constantly checks that the build has not been broken. Code reviews are also performed as branches are merged to the trunk. Feature flags can be used to toggle off features which have some code in trunk but shouldn’t yet appear on the final product. Automated tests are a further area to ensure that what is being added to trunk is release ready.