A platform with many teams and frequent releases must choose a branching model. What decides it?

Why trunk-based, with the proviso

Long-lived branches accumulate integration risk. The longer a branch lives, the larger the divergence, the harder the merge, and the later the conflicts and behavioural incompatibilities are discovered. Integration problems found at merge time are found at the most expensive moment.

Trunk-based development integrates continuously in small increments, so conflicts are small and immediate.

The proviso matters as much as the recommendation. Adopting it without the prerequisites produces a broken trunk, blocked developers and a rapid retreat — which is then read as evidence the practice does not work.

The prerequisites

• A fast, reliable pipeline. If a build takes an hour, developers batch changes — which is exactly what trunk-based development eliminates. If it is flaky, failures are ignored and broken code reaches trunk.
• Feature flags for incomplete work, since merging daily means merging work that is not finished and must be shippable-but-inactive.
• Backward-compatible change discipline, making expand-and-contract the default rather than a special technique, because trunk must be deployable at all times.
• Test coverage sufficient to trust a merge.
• Small changes as a habit — trunk with large commits is the same batching problem renamed.

When release branches are still justified

When you must support multiple versions in the field — installed software, mobile applications with slow adoption, or enterprise products with long-term support commitments. Here a release branch is a genuine requirement, and the discipline is to keep them short-lived and to cherry-pick forward rather than maintaining divergent development.

The transition that works

Shorten branch lifetime progressively — weeks to days to hours — with each step surfacing the next constraint, usually pipeline speed first and flag infrastructure second.