Engineering Practice
Trunk-based: multiple-choice review
Crux Multiple-choice synthesis across the trunk-based unit — drift, short-lived branches, feature flags, the green CI gate, merge queues at scale, and flag debt.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a call you make in a real workflow argument — not a definition to recite, but a tradeoff to defend when someone says “trunk-based doesn’t scale.”
Goal
Confirm you can connect the unit’s spine: drift sets merge cost, short-lived branches cap it, flags decouple deploy from release, the green CI gate makes the shared trunk safe, merge queues hold it at scale, and cleanup is what makes the whole trade net-positive.
Quiz
Completed
One engineer merges a 2,000-line feature the same hour they forked; another merges a 50-line fix from a three-week branch. Which merge is more expensive, and why?
Heads-up Diff size doesn't drive merge cost; divergence does. A big change merged the same hour reconciles near-zero drift because trunk hasn't moved — it's near-free.
Heads-up Same algorithm, very different inputs. The cost is the volume of divergent commits and lost context to reconcile, set by branch lifetime, not the merge tool.
Heads-up Review depth isn't the point. The same 50 lines are cheap on a fresh trunk and expensive on three weeks of drift — lifetime, not review, is the variable.
Quiz
Completed
A team reads 'trunk-based development,' turns off branch protection, and commits straight to main. A week later trunk is red twice a day and a credential leaked. What did they actually get wrong?
Heads-up Pure commit-to-trunk exists for small paired teams but still relies on a fast green gate. The model forbids long-lived branches, not the PR/CI safety mechanisms.
Heads-up The failure was dropping the gate and review, not the branching model. DORA data shows trunk-based correlates with elite delivery when the gate and discipline are present.
Heads-up Adding a develop branch re-introduces the integration phase and drift trunk-based removes. The fix is a fast blocking gate plus short-lived branches, not a long-lived staging branch.
Quiz
Completed
An engineer insists they can't integrate daily because their checkout rewrite isn't finished and 'you can't put half a flow on trunk.' What dissolves the objection?
Heads-up That is exactly the drift-accumulating long-lived branch the unit exists to eliminate; the flag gives unfinished work a safe home on trunk instead.
Heads-up Build speed isn't the blocker. The hidden assumption is that deploying equals exposing to users — a flag breaks that link so incomplete code can ship hidden.
Heads-up Flagged code still goes through the gate and review. The flag changes exposure, not the requirement to review and pass CI.
Quiz
Completed
You must replace the ORM across a continuously deployed service; the migration will take six weeks. What's the trunk-based way to do it?
Heads-up Six weeks of divergence on a continuously deployed service is the big-bang merge and semantic-conflict detonation trunk-based avoids. The team builds on a trunk that branch knows nothing about.
Heads-up Gitflow's stabilization phases suit scheduled shrink-wrapped releases, not continuous deploy. It institutionalizes the integration phase and long-lived branch you're trying to avoid.
Heads-up Code freezes are a DORA anti-pattern — they stall the team and move the integration pain to thaw day. Branch by abstraction lets normal work continue on trunk.
Quiz
Completed
At 50 PRs/day on one trunk, every PR is green before merge yet trunk still breaks a few times a week. What's the right fix?
Heads-up Each PR is still validated against a stale base, so two independently-green PRs can combine to break trunk. The problem is the state you test against, not review depth.
Heads-up Post-merge testing detects breakage only after it blocks the team, and at this volume the revert churn is constant. The gate exists to keep trunk green, not to clean it up after.
Heads-up That abandons trunk-based to dodge a solvable infra problem, trading the queue bottleneck for weekly big-bang merges and reabsorbed drift. Scale the gate, not the branches.
Quiz
Completed
Two years in, a trunk-based team has 400 flags, a 'new checkout' flag at 100% for a year with the old path still behind the else, and an incident from two flags whose combination was never tried. What's the root failure?
Heads-up Flag debt is avoidable with lifecycle discipline — owners, expiries, and deleting the flag and dead path as the closing step of rollout. The debt only piles up when cleanup is skipped.
Heads-up Branches re-introduce drift and big-bang merges. Flags are the right tool; the discipline is to remove release flags at 100%, not to avoid flags.
Heads-up The cost isn't runtime latency — it's the combinatorial space of untested configurations and the rotting old paths behind stale release flags.
Recap
The through-line of the unit is one disciplined system, not a branching trick. Drift sets merge cost, so short-lived branches (three or fewer, gone within a day) cap it; feature flags decouple deploy from release so unfinished work rides on trunk dark and big refactors use branch by abstraction; the fast blocking green gate makes the shared trunk safe and merge queues hold it green at scale; and cleanup — delete the branch on merge, the flag on full rollout — is what stops branch debt from reappearing as 2^N flag debt. Adopt the branch model alone and you get the failure modes; adopt the whole system and the DORA numbers follow.