A team wants to move from long-lived branches to trunk-based development. What must be in place first?

What must be in place

1. A fast, reliable pipeline. If a build takes an hour, developers batch changes, and batching is exactly what trunk-based development is trying to eliminate. If it is flaky, people ignore failures and broken code reaches trunk.

Fast and trustworthy is the prerequisite; everything else depends on it.

2. Feature flags for incomplete work. Merging to trunk daily means merging work that is not finished, so it must be shippable-but-inactive. Without flags, teams either hold branches or ship half-built features.

3. Backward-compatible change discipline, especially for schemas and interfaces. Trunk is deployable at all times, so every change must be safe to release — which means expand-and-contract as the default rather than as a special technique.

4. Test coverage sufficient to trust a merge. Trunk-based development moves the safety net from review of a large branch to automated verification of a small change.

5. Small changes as a habit. Trunk-based development with large commits is the same batching problem with a different branch name.

6. Deployment safety — canary or progressive rollout with automatic rollback — so a defect that reaches production is contained.

What it delivers

• No merge hell. Integration happens continuously in small increments, so conflicts are small and immediate rather than large and archaeological.
• Faster feedback, since problems surface within hours rather than after a long-lived branch is merged.
• The codebase is always releasable, which decouples the decision to release from the state of the code.
• Better collaboration, since everyone sees everyone's changes promptly.

The transition that works

Shorten branch lifetime progressively rather than switching overnight — from weeks to days to hours. Each step surfaces the constraint that must be fixed next, usually pipeline speed first and then flag infrastructure.

The failure to avoid

Adopting trunk-based development without the prerequisites, which produces a broken trunk, blocked developers, and a rapid retreat to branches. The retreat is then read as evidence that the practice does not work, when what did not work was adopting it without a fast pipeline and flags.