Having worked at companies ranging from tiny startups, to massive organizations like Google and Airbnb in my career so far, I’ve seen wave-after-wave of developer workflows quickly rise and fall in popularity. One of them, however, has stood the test of time and demonstrated value across eng orgs of all sizes: trunk-based development.
What is trunk-based development?
Trunk-based development (TBD) is a workflow where all developers work off of a single, shared main branch (the "trunk") and integrate their changes frequently. Keeping all dev branches based on trunk and short-lived greatly streamlines the merge process, as conflicts are far less common. To further illustrate the merits of TBD, let's compare it to its closest predecessor, the feature branch workflow.
Trunk-based development vs. feature branches
Feature branching traces its roots back to the days of the Waterfall Model of software development, when changes were large, structured, and implemented in stages. Feature branches are like isolated playgrounds where developers can freely work on their specific features, independent of the work done by others. They can live independent of other changes for weeks or months at a time. The downside, however, is that unless you have an extremely specific use case (i.e. some mobile app development, where release speed is heavily gated by the app stores), feature branch development introduces too much siloing in your codebase. By design, feature branches are isolated from each other and long-lived, thus isolating the individual engineers working on them. Not only does this discourage collaboration within the eng team, it also all-but-ensures merge conflicts when different engineers try to merge in their long-running branches to deliver their projects.
For organizations that have bought into continuous integration/continuous delivery (CI/CD) and want to develop quickly, TBD is quickly becoming considered a best practice for the following reasons:
Team synchronization: In TBD, developers base all of their changes on the trunk branch and integrate them more frequently, promoting a better team culture by keeping everyone informed about each other’s work.
Fewer merge conflicts: TBD encourages regular commits and merges, thereby reducing the risk of serious merge conflicts that can arise when branches diverge extensively in a feature-branch workflow.
Simplified continuous integration (CI): Regular commits to trunk imply that the codebase is always current, paving the way for a more efficient integration with CI.
Optimized continuous delivery (CD): TBD necessitates maintaining the trunk in a deployable state, which aligns neatly with CD.
Faster feedback loops: TBD minimizes the interval between writing and deploying code to production, meaning faster feedback from users.
Promotes better practices: TBD encourages other best practices, like feature toggling and regular refactoring.
Industry leaders like Google and Facebook have long recognized these advantages, using TBD in their development for years. In fact, according to a 2021 Google Cloud report, “elite performers who meet their reliability targets are 2.3 times more likely to use trunk-based development. Low performers are more likely to use long-lived branches and to delay merging.”
Does Trunk-based development lead to higher velocity?
Based on millions of PRs synced with Graphite, trunk-based development can yield concrete speed improvements. PRs based on trunk branches see a nearly 10-hour reduction in PR open-to-merge time compared to PRs with other merge bases.
Much like we saw with banning merge commits, our data suggests that larger, higher-performing organizations are more likely to have implemented trunk-based development:
Lastly, we can see that this trend has only been increasing over the last decade, culminating in almost 80% of PRs merged in 2023 being based on “main” or “master” rather than a feature branch. Excluding stacked pull requests, we expect this trend to continue increasing in the coming years.
Say “no” to feature branches
The advantages Trunk Based Development offers in terms of CI/CD, reduced merge conflicts, and fast feedback loops make it a far better choice than long-lived feature branches for organizations aiming for high-velocity, high-quality software development. Adopting TBD may involve a shift in mindset and operational habits if you’re used to older development practices, but the benefits it brings are well worth the effort.
Try it out, look at your own stats, and let me know what you think!