Trunk-based development (TBD) is a branching model for software development where developers merge every new feature, bug fix, or other code change to one central branch in the version control system. This branch is called “trunk”, “mainline”, or in Git, the “master branch”.
Trunk-based development enables continuous integration – and, by extension, continuous delivery – by creating an environment where commits to trunk naturally occur multiple times daily for each programmer. This makes it easy to satisfy the “everyone on the development team commits to trunk at least every 24 hours” requirement of continuous integration, and lays the foundation for the codebase to be releasable at any time, as is necessary for continuous delivery and continuous deployment.
Styles of TBD
Depending on the size of the development team, two different styles of trunk-based development emerge: small teams will tend to simply merge every new change to trunk, while larger teams may use short-lived branches, owned by one person/pair, or a small team. These branches will be merged back to trunk within days of being cut from it. (Any changes that require more than a few days to make should be done using feature flags in a branch by abstraction method in order to prevent “merge hell” from long-lived feature branches.)
The only long-lived branches in trunk-based development are release branches, managed by a release engineer. Developers don’t make commits directly to release branches, although the release engineer may sometimes take a particular developer’s commit and merge it into the release branch.
Release branches are never merged back to trunk. They are created at the beginning of a major version and merged into from trunk for minor versions, but when it’s time to begin another major version, the existing release branch is deleted and a new one is created from trunk.
Pull Requests in TBD
Many people think of pull requests and imagine GitFlow, which is almost the polar opposite of trunk-based development (slow & fault-tolerant, contrasted with TBD which is fast-paced & developer-trusting). But pull requests do have a place in TBD – under specific circumstances. Using feature branches responsibly, a developer will, at any given time, still have some code which has not been merged to trunk yet. A pull request could be made to initiate a code review (especially an automatic one by a CI tool) on this new code.
When to Use Trunk-Based Development
There are two key features of TBD to consider when deciding whether or not to implement it. First, TBD has the ability to move very quickly. Second, it’s very trusting of developers: no matter what they do, they are trusted to not break the build. These are commonly espoused as benefits of trunk-based development – and they are – but no system works perfectly for everyone.
For example, a brand-new company that needs to create version 0.0.1 of its product as soon as possible and has a team comprised of experienced engineers will work perfectly with TBD: everyone who would be committing to trunk is trusted, and speed is critical. However, a group of developers maintaining an established open-source project will not: speed is less important for them, and they can’t possibly trust every random person who opens a Github pull request. The latter team would be better off using a more fault-tolerant process (such as GitFlow).