Trunk-based vs feature branches
Both models use feature branches. The difference is how long they live. Two days vs two weeks looks similar on paper. The cost is not similar at all.
In one paragraph
The classic feature-branch model gives every feature its own branch and lets that branch live until the feature is done. Trunk-based development uses branches too, just much shorter ones. Same primitive, different lifetime, very different cost. Long branches diverge from main, accumulate semantic conflicts, and turn integration into a project.
Long-lived feature branches
Two-week feature branches
Two parallel feature branches living for two weeks each. The longer they live, the more main moves underneath them. "Merge week" is what happens when both come back at once.
The model is simple from inside the branch. An engineer takes a branch, works on the feature until it is done, opens a PR, gets review, merges. From outside the branch, a different story unfolds.
While that branch lives, main keeps moving. Other engineers ship. Functions get renamed. Dependencies bump. Internal APIs evolve. By the time the long branch comes back, it has to be reconciled with two weeks of unrelated change. Git resolves the textual conflicts. The semantic conflicts (a function signature that changed, a callsite that no longer exists) silently pass review and break main on merge.
The cost is not linear in branch lifetime. A two-day branch is roughly a regular merge. A two-week branch is a project. A two-month branch is the kind of thing teams quietly abandon.
Short-lived branches
Trunk-based, branches under one day
The same two weeks of calendar time. Each PR opens and closes within one day. Integration is constant, never episodic. Main never accumulates the kind of drift that breaks merge weeks.
Trunk-based development uses the same branch primitive, but on a much tighter cycle. Branches open in the morning, merge by end of day, and the engineer pulls main again. The branch never gets far enough from main to develop semantic drift.
The work that used to fit in one large branch (a multi-day feature, a refactor, a migration) gets split into small PRs that ship behind feature flags or stack on top of each other. The feature still takes two weeks to build. The branch never lives that long.
The cost of long branches
Integration cost grows faster than branch lifetime. The bars below scale with hours of cleanup time, and the curve is roughly geometric.
The shape of the curve matters more than the exact numbers. Doubling branch lifetime more than doubles the cleanup cost. By the time you reach a month, the cleanup eats the time you "saved" by not integrating earlier, and then some.
"But our features take longer than a day"
They do. Trunk-based development does not assume features fit in a day. It assumes branches do. The pieces that make this distinction work in practice:
- Feature flags let unfinished features ship to main behind an off switch. The branch closes when the next slice of work merges, not when the feature is complete.
- Stacked PRs chain dependent branches together so a multi-day refactor lands as five small reviewable pieces.
- Branch by abstraction wraps a piece of code in an interface, ships the new implementation behind it, switches traffic, and deletes the old code. Each step is a small PR.
- Splitting a big feature into "scaffolding," "primary path," and "edge cases" is usually possible, even when it does not feel like it.
The skill teams build over a few quarters is the ability to look at a multi-day piece of work and see the smaller, shippable units inside it. The branch lifetime tracks the units, not the feature.
Short-lived branches need a green main.
Multiple PRs landing on main in a single day means the merge queue is doing real work. Mergify is what most trunk-based teams use to keep main from ever turning red.