How many long-lived maintenance branches should a project keep, and how do you bound the backport cost?

## The cost model The question is a budgeting question dressed as a Git question. Every additional supported line multiplies the work for *every* fix that applies to it: a port (merge or cherry-pick), a conflict resolution when the code has drifted, a full test run on that line's dependency set, a release build, an annotated tag, and a publication. Three lines is not 50% more work than two; it is more, because the third line is usually the oldest, therefore the most drifted, therefore the one where the patch does not apply cleanly. The second term is time. Drift accumulates: every refactor, rename, formatting change or dependency upgrade that lands on one line and not another widens the textual distance a future patch must cross. A branch that was trivially mergeable at month three requires hand-porting at month eighteen. So the cost of a line is not a constant per fix — it rises for as long as the line stays alive. ## Choosing the number Start from the promise you are willing to keep, not from what feels safe. In practice that is usually the current release line plus one predecessor, with a longer-lived line only where an explicit commitment exists — a contractual support window, a customer who cannot upgrade, a platform that pins you. Each line should have a **published end-of-life date** decided when the line is cut, not negotiated when it becomes inconvenient. Without that date, lines never die, because the cost of keeping one alive is diffuse while the cost of ending it is a conversation. Retiring a line in Git is cheap and reversible: stop merging into it, delete the branch, and keep the annotated tags. The tags keep every shipped commit reachable, so the history is preserved permanently and the branch can be recreated from a tag (`git switch -c release/1.4 v1.4.7`) if something forces you back. That asymmetry — deletion is cheap, resurrection is one command — is the argument for retiring aggressively. ## The mechanisms that bound the cost **Order the lines and merge forward.** If the live lines form a chain, a fix goes onto the oldest affected line and is merged forward through the others. One commit, N-1 merges, and reachability then proves coverage: `git branch --contains <sha>` lists every line and `git tag --contains <sha>` every release that carries the fix. Fanning independent cherry-picks out to each line produces unrelated commits, unprovable coverage, and conflicts whenever those lines are later merged. **Keep maintenance lines boring.** The single largest lever. A maintenance branch takes fixes and nothing else: no refactors, no reformatting, no opportunistic dependency bumps, no "while I was in there". Every such change is a permanent tax on every subsequent backport to that line. **Tag everything, annotated.** An annotated tag per shipped build turns incident triage into a query. `git tag --contains <sha>` answers "which released versions have this fix", `git tag --sort=-v:refname -l 'v1.4.*'` lists a line's releases in version order, and `git describe` on any build stamps it back to a commit. Without tags, the same questions become archaeology. **Audit, do not trust.** Before cutting a release, run `git cherry -v main release/1.4` and review every `+`: those are commits on the maintenance line with no equivalent upstream. Some are legitimately line-local (a version bump); the rest are fixes somebody forgot to propagate. Making that review a gate is how the classic "the hotfix never reached main" regression stops happening. **Reduce repeated conflict cost.** `rerere.enabled = true` records conflict resolutions and replays them when the same hunk conflicts again, which is common when the same forward merge runs every week. ## The tradeoff to articulate More supported lines buy customers time to upgrade and buy you goodwill; they cost engineering throughput and, more insidiously, they cost *attention* — a fix applied to four lines is four chances to make a mistake under incident pressure, on the lines you exercise least. Fewer lines force upgrade pressure onto customers, which is a product decision with real consequences and must be owned as one, not smuggled in as an engineering preference. The honest framing for an interview: name the support promise first, derive the branch count from it, then show the Git-level mechanisms — merge-up ordering, boring maintenance lines, annotated tags, `git cherry` audits — that keep the derived cost from compounding. A candidate who answers with a number and no promise behind it has missed the question; so has one who lists Git commands without acknowledging that the real variable is how long lines are allowed to live.