Short-lived branches vs gitflow

A team reads “trunk-based development” and hears “commit straight to main, no branches, no PRs.” They turn off branch protection. Within a week the trunk is red twice a day, an unreviewed change leaks a credential, and they conclude trunk-based “doesn’t scale.” They threw out the wrong thing. Trunk-based was never about deleting branches — it’s about keeping them so short-lived that they never accumulate drift. The branch lives for an hour, behind a green gate and a review, then it’s gone.

What “short-lived” actually specifies

DORA’s definition of trunk-based is concrete, not vibes. Keep three or fewer active branches in the repository at any time. Branches should last no more than a day before merging into trunk — often only a few hours. There are no code freezes and no integration phases. Each branch is one small, scoped change that opens a PR, passes a fast CI gate, gets a quick review, and merges the same day. The branch is a staging area for review and gating, not a place where work lives.

This is sometimes run as pure “commit to trunk” (no branches at all, common in small co-located teams with pairing) and more often as “short-lived feature branches” (the version most teams use, because it keeps code review and the PR gate). Both are trunk-based. The dividing line isn’t “branch or no branch” — it’s lifetime. A branch that lives hours is trunk-based; a feature/* branch that lives two weeks is the long-lived branch the practice exists to eliminate, no matter what you call your workflow.

Why gitflow optimizes for the opposite world

Gitflow gives you permanent main and develop branches, plus feature/*, release/*, and hotfix/* branches with formal phases: features integrate into develop, a release branch stabilizes, then merges to main and tags. It’s a coherent model — for the world it was designed for: shrink-wrapped, versioned software with scheduled releases, multiple versions supported in the field, and no continuous deployment. In that world, an explicit stabilization phase and parallel release lines earn their keep.

For a continuously deployed web service, gitflow institutionalizes exactly the drift the previous lesson warned about. Long-lived feature/* branches accumulate divergence; the develop-to-release-to-main promotion is a built-in integration phase; “done” features sit in develop rotting while they wait for the next release train. You inherit big-bang merges and code freezes by design. DORA’s research explicitly flags integration phases and code freezes as anti-patterns for delivery performance — gitflow makes them load-bearing.

Releasing without long-lived branches

The objection: “if there’s only trunk, where do releases come from, and how do I patch an old version?” Trunk-based has a specific answer — branch for release, not for feature. When you cut a release, you create a short-lived release/x.y branch from trunk at that commit. Day-to-day development never happens on it. If a critical fix is needed, you fix it on trunk first (so the next release has it too) and cherry-pick the single commit onto the release branch. The release branch is a read-mostly snapshot, not a parallel development line, so it never accumulates drift. Teams doing continuous deployment often skip even this and just tag trunk.

For big changes that genuinely can’t ship in a day — replacing an ORM, swapping a payment provider — the trunk-based tool is branch by abstraction, not a long-lived branch. You introduce an abstraction layer over the thing you’re replacing, build the new implementation behind it incrementally on trunk (each step merged daily, dark until ready), switch the abstraction to the new implementation, then remove the old one and the abstraction. The large refactor lives on trunk the entire time as a sequence of small green commits — never as a three-week branch.