Trunk-Based Development

Trunk Based Development is a source control strategy where developers commit all changes to a single branch in the version control system known as the 'trunk'. This approach minimises the duration and size of branches and encourages frequent integrations.

Goal

The goal of Trunk Based Development is to speed up the development process by reducing the complexity of each commit, reducing merge conflicts and lowering lead time for changes.

Context

Code versioning systems enable branching which lets developers work on features or bug fixes in isolation. However, long-lived branches can lead to integration issues and conflicts when merging back into the main branch. In addition, they make continuous integration more complex as there are different test code bases for each branch as well. Trunk Based Development aims to address these issues by promoting frequent integrations and reducing the complexity of each commit.

Why not Git Flow?

Git Flow was designed to let multiple teams work in parallel without stepping on each other. Each feature gets its own branch, branches are merged back to a develop branch, and develop is eventually merged to main for release. The problem is that Git Flow is antithetical to continuous integration. CI verifies that everyone's changes work together on every commit. That only works if everyone's changes are actually together. Long-lived feature branches keep the changes apart by design.

Three predictable outcomes follow:

1. Merge hell. The longer a branch lives, the more the trunk diverges from it. Resolving the eventual merge becomes a multi-hour exercise that often introduces bugs no test suite was designed to catch.
2. Hidden integration risks. The fact that two features each pass their own tests in isolation tells you nothing about whether they work together. Bugs from interaction between branches surface only at merge time, when the team has already moved on.
3. A second set of dependencies. If your branch depends on something in another team's branch, you now have a code-level coupling that mirrors the team coupling. The codebase has been split along the same lines as the org chart, which is exactly what value-stream alignment was supposed to remove.

Trunk-based development inverts the trade-off. Everyone commits to the trunk, all changes are integrated as they happen, and feature flags hide work-in-progress from end users until it is ready. The risk shifts from "will the merge work?" (a problem that is felt only at the end) to "is the trunk green right now?" (a problem the team can fix in minutes with the right CI and test discipline). The cost is the learning time to shift to short-lived branches where you have tests in place before changes land and working in small steps. The benefit is that integration stops being a separate phase of the work.

Enablers

If teams are committing to the main branch frequently, they need to ensure that the branch is always in a deployable state. To achieve this, there are a few essential practices.

Inputs

Outputs

Anti-patterns

• Large, Infrequent Commits: Neglecting to commit small changes frequently can lead to integration nightmares and conflicts.
• Ignoring Failing Builds: Not addressing build failures immediately can result in a destabilised trunk, affecting all team members.