What must a team have in place before moving from long-lived branches to trunk-based development?
answer
- It is a consequence, not a policy you declare
- Ask what the single shared line demands
- Splitting work is a codebase property
- Some long-lived branches are requirements
- Sequence the migration; measure branch age first
basics
~20 sAutomated verification the team actually trusts on every merge, changes that can be split into small independently-shippable pieces, a way to keep unfinished work inert on the trunk, and a release model that does not require several shipped versions to be maintained in parallel.
solid answer
~50 sTrunk-based development is a consequence of other capabilities, not a policy you can simply declare. The prerequisites are: verification on every merge that is fast and trustworthy enough that a green trunk means something, because everyone now builds on that one line; the engineering ability to split work into small independently-mergeable pieces, which usually means the codebase has seams; a mechanism — flags or branch by abstraction — that lets incomplete work sit on the trunk without being reachable; and a release model where one line can serve, since supporting several shipped versions in the field genuinely requires maintenance branches. It is a poor fit when contributors cannot push at all, or when regulatory separation demands isolated lines. The sensible migration is incremental: cap branch age first, then shrink batch size, then remove the intermediate long-lived branches — because shortening branches without the ability to split work just produces the same large merges under more time pressure.
go deeper
Know that the model depends on more than a rule about branch length: automated checks on every merge, small changes, and a way to keep unfinished work switched off.
Explain each prerequisite in terms of what the shared trunk demands, and why a flaky test suite is more damaging here than in a model with isolated branches.
Show that you would sequence the change — reliable checks, then a branch-age cap, then the inert-work mechanism — and name the failure you expect when the order is wrong.
Own the fit decision and the tradeoffs: which release obligations rule the model out, how you measure adoption rather than declare it, and the review-throughput cost that many small changes create.
## Frame it as capability, not policy The common failure is announcing trunk-based development as a rule — "branches merge within a day" — while the conditions that make short branches possible are absent. Teams then either miss the rule constantly or merge unfinished work with no way to keep it inert, and the trunk stops being releasable. The right framing in an interview is that trunk-based development is the *visible consequence* of four underlying capabilities. ## Prerequisite one: verification you trust One shared line means one shared failure mode. If the trunk breaks, everyone integrating is blocked, so the checks that run on every merge have to be both trustworthy and fast. Trustworthy matters more: a suite with intermittent failures trains people to ignore red, and an ignored signal on a single shared line is worse than no signal, because everyone is building on it. Before shortening branches, fix the flaky checks. Speed matters because the verification window is the interval during which someone else's merge can make your verified state stale. ## Prerequisite two: changes that can be split Small batches are what make a one-day branch possible. Whether work can be split is a property of the codebase, not of the developers' willpower. If every change touches a central module with no seams, pieces cannot be landed independently and long branches reappear regardless of policy. This is why branch-by-abstraction skills and the refactoring that creates seams are a genuine precondition — and why the first real work of a migration is often in the code, not the process. ## Prerequisite three: unfinished work can be inert The trunk must stay releasable while it carries work in progress. That requires flags or abstraction seams and, critically, the discipline to remove them when the change lands. Without removal, the codebase accumulates permanent alternative paths — divergence relocated from the repository into the source, where it is harder to see and harder to delete. ## Prerequisite four: a release model one line can serve This is the honest boundary. Trunk-based development assumes the trunk is what ships. If several released versions must be supported simultaneously in the field, maintenance branches are not a habit to break — they are the requirement. If contributors cannot push to the repository at all, contribution arrives as forks or patches by necessity. If an audit regime demands separated lines, that is a constraint, not a preference. A principal-level answer names these as legitimate reasons the model does not apply, rather than treating every long-lived branch as a discipline problem. ## Migration order Sequence matters, because doing it in the wrong order produces the same merges with more stress: 1. **Measure.** Branch age at merge and merge size are the two numbers that describe where you are. Both are readable from history, so the baseline is objective rather than anecdotal. 2. **Fix the signal.** Make the checks reliable before making anyone depend on them more. 3. **Cap branch age.** A ceiling — say a week, then three days — forces the splitting problem into view without demanding the end state immediately. 4. **Build the inert-work mechanism.** Flags and seams, plus the convention that removal is part of done. 5. **Collapse the extra long-lived branches.** Remove the intermediate integration lines last, once nothing depends on them for isolation. ## What you should expect to go wrong The predictable failures are worth naming, because an interviewer is listening for whether you have done this rather than read about it. Branch-age caps get met by merging unfinished work with no flag, so the trunk becomes unreleasable. Flags are added and never removed, so the code fills with dead paths. The team blames the model for breakages that are really an unreliable test suite. And review pressure rises, because many small changes need many small reviews — which is a real cost, not an illusion, and it has to be planned for rather than discovered. ## The closing judgment The strongest answer resists universalising. Trunk-based development is excellent where one line ships continuously and the codebase supports incremental change. Where it does not fit, the mature move is to say so and pick the model that matches the release obligations — while still borrowing what transfers: smaller batches, shorter branches, and merging early rather than at the end.
- What measurements tell you whether a team is really trunk-based?Branch age at merge and the size of each merge — both derivable from history by comparing a branch's first commit and merge base against its merge. Policy statements tell you nothing; a distribution of branch ages tells you everything, and the tail of that distribution is where the risk lives.
- Name a case where long-lived branches are the correct answer, not a discipline failure.Supporting several released versions in the field at once. Each supported line needs its own branch to receive fixes, because customers on an older version cannot take the trunk. Contribution from people without push access is another: the isolation comes from the fork, not from a habit anyone chose.
- What goes wrong when a team caps branch age without first learning to split work?The same large change is merged under time pressure instead of being split — often unfinished and with no mechanism to keep it inert — so the trunk stops being releasable. The cap makes the symptom visible without addressing the cause, which is the missing seams that would let the work land in pieces.
saying these in an interview costs you the question
- Treats trunk-based development as a universal best practice
- Declares a branch-age rule without splitting ability
- Ignores that a shared trunk needs trustworthy checks
- Adds flags with no removal expectation
- Dismisses maintenance branches for supported releases