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

What is being tested

Whether you know the prerequisites, and whether you recognise that adopting the branching model without them produces a broken mainline rather than faster delivery.

The prerequisites

1. Feature flags. Incomplete work must be safely unreachable in production. Without them the team faces an impossible choice: block merging until a feature is complete (which is long-lived branches by another name), or ship half-built behaviour.

2. A fast pipeline. Beyond about ten minutes for the commit stage, behaviour changes: people batch changes and stop waiting for feedback, which reintroduces large batches.

3. A trustworthy pipeline. A flaky build trains people to re-run rather than investigate, and its signal becomes worthless — after which a red mainline is ambiguous and the stop-the-line norm collapses.

4. Expand-and-contract schema changes. If a migration can break the previous version, the database blocks the mainline and every schema change needs coordination.

5. Automated rollback. Merging frequently to a shared mainline is only safe if a mistake is cheap to reverse.

6. A stop-the-line norm. A red mainline is the team's top priority. Without this the discipline erodes within a month, because people work around a broken mainline rather than fixing it.

7. Small changes as a habit. This is the hardest prerequisite and the least technical. It is a skill — decomposing work into safely mergeable increments — and it takes practice.

The objections and their answers

"We need branches for code review." Short-lived branches merged the same day preserve review entirely. The objection is really about review latency, which is the thing to fix — and which is worth fixing regardless.

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

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

Why it matters

Merge cost grows non-linearly with divergence. Two branches open for three weeks do not conflict twice — they conflict with each other and with the mainline, resolved by whoever merges last, under pressure, with the least context. The combinatorics get worse with team size, which is why the pain appears suddenly as a team grows.

How to sequence the change

Pipeline speed and reliability first. Then flags. Then reduce branch lifetime gradually — a week, then two days, then one. Then expand-and-contract migrations as they arise. Attempting the branching change first, without the prerequisites, produces a broken mainline and a team that concludes trunk-based development does not work.