In trunk-based development, how do you merge unfinished work into main safely?

## The problem being solved Trunk-based development asks for branches that live hours or days. Real features take longer. The apparent contradiction dissolves once you separate two things people conflate: **merging code** and **activating behaviour**. A long-lived branch keeps unfinished work out of the trunk by keeping the *code* out. Trunk-based development keeps the *behaviour* out instead, and lets the code merge continuously. That is the whole idea. Everything below is technique for making incomplete code harmless once it is on the trunk. ## Flags The simplest form is a runtime condition around the new path, off by default in production, on in development or for internal users. The new code is compiled, tested, reviewed and shipped; it is just not reached. Because the code is on the trunk, everyone else's changes are merged against it from day one, so it never drifts. From the Git side, this changes what a commit looks like: instead of one merge introducing a whole feature, you get a series of small commits that each add an inert piece, and eventually one small commit that flips the default. The design of the flag system itself — how flags are evaluated, targeted, and rolled out to a percentage of users — is a separate discipline with its own tradeoffs, and not a Git question. ## Branch by abstraction The second technique handles the case a flag handles badly: replacing something large and pervasive, where a condition at the call site would have to be repeated everywhere. The steps are mechanical and each one is mergeable on its own: 1. Introduce an abstraction — an interface or seam — in front of the existing implementation, and route all callers through it. Behaviour is unchanged; this commit is pure refactoring. 2. Add the new implementation behind the same abstraction. It is not selected yet, so it is dead code on the trunk, but it is compiled and tested there. 3. Move callers or traffic to the new implementation incrementally, one area at a time, each as its own small change. 4. Delete the old implementation. 5. Optionally, remove the abstraction if it existed only for the migration. At no point is there a branch holding half a migration, and at no point is the trunk unreleasable. A rollback at any step is a small revert rather than an unpicking of a huge merge. ## Why this is a Git-workflow topic at all Because it is the answer to the obvious objection to trunk-based development. An interviewer who asks "how can you merge daily when a feature takes three weeks?" is testing whether you understand that the model relocates the isolation from the branch to the code. Candidates who have not internalised that usually claim trunk-based development only suits trivial changes. It also has direct consequences for how you commit. Work must be split into pieces that are individually safe and individually reviewable, which shapes the commit sequence and the size of each merge. A change that cannot be split that way is a signal about the codebase — often that a seam is missing — and that signal is exactly what branch by abstraction responds to. ## The cost, stated honestly Both techniques put temporary structure in the codebase: a condition that will never be false again, an abstraction with one implementation, a dead code path nobody removed. That debt is real, and it compounds because each leftover makes the code harder to read for everyone. So the last step is not optional. The change is finished when the flag and the code it guarded are gone, or when the old implementation and the migration-only abstraction are deleted — and those removals are themselves small commits on the trunk. Teams that treat the cleanup as part of the work keep the model sustainable; teams that treat it as follow-up eventually have a codebase full of forks that no branch ever contained. ## What a strong answer includes Name both techniques, explain that they move isolation from the branch to the code, walk one migration through its steps, and state the cleanup commit as part of the definition of done. Mentioning that the merge stays small at every step — and that a rollback is therefore a small revert — shows you understand why the model reduces risk rather than just relocating it.