Trunk-Based Development in Practice

Definition

All developers commit to a single mainline at least once a day. Branches, where used, live hours rather than weeks. Incomplete features are merged behind flags rather than kept apart.

Why it beats long-lived branches

Merge cost grows non-linearly with divergence. A branch open for three weeks conflicts with everything, and the conflicts are resolved by whoever merges last, under pressure, with the least context. Two branches open simultaneously do not conflict twice — they conflict with each other and with the mainline, and the combinatorics get worse with team size.

It is the prerequisite for continuous integration. A team with an excellent pipeline and long-lived branches has automated builds and the same integration problem they always had. Integration is the thing being made continuous, not the build.

Feedback is immediate. A defect introduced today is found today, when the author remembers the change, rather than at merge time in three weeks.

What it requires

• Feature flags, so incomplete work is safely unreachable in production.
• A fast, trustworthy pipeline. If the mainline breaks often and takes an hour to verify, people will avoid it.
• Small changes, which is a habit rather than a tool and the hardest part to establish.
• Expand-and-contract for schema changes, so the database never blocks the mainline.
• A stop-the-line norm when the mainline is red.

The common objections and their answers

"We need branches for code review." Short-lived branches — hours, merged the same day — preserve review. Or pair programming, which reviews continuously. The objection is really about review latency, which is the thing to fix.

"Incomplete work would reach production." That is what flags are for. Deployed is not released.

"Our releases need stabilisation." A stabilisation period is evidence that the mainline is not trustworthy, which is the actual problem. Making the mainline always releasable removes the need.

Failure scenarios

• Trunk-based in name, with branches quietly living for a week.
• No flags, so incomplete work either blocks merging or breaks production.
• A slow pipeline, so people batch changes to avoid waiting.
• A red mainline tolerated, which destroys the discipline within a month.

Interview question

"What has to be true before a team can safely move to trunk-based development?"