Trunk-based development has a reputation for being anti-review, and it is unearned. The canonical reference describes a model where developers collaborate in a single branch called trunk, resist long-lived development branches, and commit multiple times a day. But it also explicitly blesses short-lived feature branches for exactly two purposes: code review and build checking. Trunk based development code review is not an afterthought bolted onto the model. It is the model, with one non-negotiable property: it has to be fast.
The short answer: Trunk-based development does not remove code review; it constrains it until review stops being a bottleneck. Branches live hours or a day or two, so diffs stay small. Diffs stay small, so reviews finish fast. Reviews finish fast, so branches can stay short. Feature flags decouple deploying code from releasing features, which removes the last excuse for long branches. Break any link in that loop, usually review speed, and the whole model quietly reverts to feature branches.
What the model actually prescribes
Strip away the folklore and the prescription is concrete. Everyone integrates with trunk at least daily, which is the bar Continuous Integration has always technically demanded. Branches, where they exist at all, live for hours or a couple of days, exist so that a reviewer and a build server can check the change before it lands, and are never the place where releases get cut. A build server verifies every commit to trunk, because with everyone integrating constantly, a broken trunk blocks the whole team. None of that abolishes review. It relocates review to the only place it can keep up: small changes, checked quickly, merged the same day.
Small PRs are the review model, built in
Most teams fight an endless battle to keep pull requests reviewable. Trunk-based teams get that property structurally: if every branch integrates within a day or so, a PR physically cannot grow to two thousand lines. The change is one coherent step, which is exactly the shape review works best on. We have made the case for small PRs on review quality grounds, and Google makes it on velocity grounds in their small CLs guide: small changes are reviewed faster, more thoroughly, and with less wasted rework when the design is wrong. Trunk-based development takes that advice and makes it mandatory instead of aspirational. The branching model is doing the PR-size policing your process documents never managed to do.
Trunk based development code review must be fast or the model dies
Here is the failure mode: a developer cuts a short-lived branch Monday morning, opens a small PR by noon, and the review sits until Wednesday. Now they either start the next change on top of unmerged work, recreating the stacked, drifting state the model exists to prevent, or they stall. Multiply by a team and trunk-based development degrades into feature-branch development with extra steps. Review latency is the load-bearing number. Google’s reviewer speed guide draws the line at one business day for a first response, and frames slow review as a team-velocity problem, not a reviewer-convenience problem. Trunk-based teams need to treat that as a ceiling, not a target, which is why they benefit most from explicit review SLAs. Tooling matters here too; ours (Pyor) exists largely because a reviewer who gets the diff organized by what matters first can turn a review around in the window trunk-based development actually allows.
Feature flags decouple deploy from release
The classic argument for long-lived branches is hiding unfinished features until they are ready. Trunk-based development answers with feature flags: merge the incomplete code, keep it dark behind a flag, and release by flipping configuration rather than by merging a branch. The canonical guidance pairs this with branch by abstraction for longer structural changes, and describes flags as a way of hedging on the order of releases. For review, this is a quiet win. The reviewer sees small, integrated slices of a feature as they land, instead of one giant reveal at the end. The cost is real: flags are code, they accumulate, and unflagged cleanup is a review item of its own. But reviewing ten small flagged PRs beats reviewing one thousand-line merge every time.
When review becomes post-commit sampling
Some mature trunk-based teams go further: commit straight to trunk, review after the fact, sometimes only a sample. That is a legitimate end state, not a cheat, but it is a different contract. Pre-merge review is a gate; post-commit review is monitoring, the shift we described in human in the loop vs on the loop. The honest prerequisites: a build server that verifies every commit, deploys that are easy to revert, blast-radius awareness about which paths still get pre-merge eyes, and an actual sampling discipline rather than review quietly stopping. Auth, payments, and data migrations should stay gated even when everything else flows. Post-commit sampling is what review looks like when trust and automation are both high. It is earned, and it is reversible the moment defect rates say so.
The loop to protect
Everything above is one feedback loop. Short branches keep diffs small; small diffs keep reviews fast; fast reviews keep branches short; flags keep unfinished work merged instead of hidden. Protect the loop at its weakest link, which in most organizations is reviewer turnaround, and trunk-based development delivers the thing it promises: integration as a habit rather than an event. Let review latency creep, and no amount of branching policy will save you; the long-lived branch will come back wearing a different name.
Frequently asked questions
Does trunk-based development eliminate code review?
No. The trunk-based playbook explicitly allows short-lived feature branches whose purpose is code review and CI checking before the code integrates into trunk. What it eliminates is long-lived branches and the giant, week-old PRs they produce. Review survives, but it has to be small and fast enough not to become the new long-lived branch in disguise.
How fast does review need to be for trunk-based development?
Faster than your merge cadence. If developers integrate at least daily, a review that waits two days forces either queued work or drift, both of which break the model. Google’s reviewer guide sets one business day as the outer bound for a first response, and trunk-based teams should treat hours, not days, as the working norm.
What is post-commit review?
Code merges to trunk first and gets reviewed after, either every change or a sampled subset. It trades the gate for throughput and works only with strong automated checks, easy reverts, and a real sampling discipline. It shifts the reviewer from approving each change up front to monitoring the stream and intervening when something looks wrong.
Top comments (0)