Trunk-Based Development: One Mainline to Rule Them All

The mental model

Trunk-Based Development is like a single, fast-moving assembly line. Everyone adds their small part to the main conveyor belt (the trunk) directly, rather than building large sub-assemblies in separate workshops (long-lived branches) and trying to bolt them on later. The goal is continuous integration, not delayed, big-bang merges.

How it works

All developers work on code that they commit to the trunk branch, often called main. If branches are used, they are very short-lived, typically lasting a few hours or a couple of days at most before being integrated back into the trunk. Code on the trunk is always expected to be in a releasable state. Incomplete features are not kept on separate branches for long; instead, they are merged to the trunk and managed using mechanisms like feature flags. This practice is a key enabler for Continuous Integration (CI) and Continuous Delivery (CD).

When to use it

Adopt Trunk-Based Development when your team has a mature culture of automated testing and a robust CI/CD pipeline. It excels in fast-paced environments where the primary goal is to deploy small, frequent updates to production. It enforces discipline and close collaboration, as every developer is constantly integrating their work with the rest of the team on the same mainline.

When not to use it

TBD is risky for teams lacking comprehensive automated tests, as a single bad commit to the trunk can break the build and block the entire team. It is also less suitable for projects that need to maintain and patch multiple older versions simultaneously (e.g., supporting v1.0 while developing v2.0). In such cases, a model like GitFlow, which uses long-lived release branches, might be a better fit. It can also be challenging for open-source projects with many external, less-trusted contributors.

One canonical example

A developer needs to add a new payment option. They create a branch feature/paypal-integration from main. They make a few commits over the course of a day. Before logging off, they open a pull request. After a quick code review, it's merged back into main. The new payment logic is disabled by a feature flag because the backend work isn't finished. The key is that the branch existed for less than a day, minimizing divergence from the trunk and avoiding future merge conflicts.