How do you choose a branching model for a team that cannot release its shared line on demand?

## The question behind the question An interviewer asking which branching model you would use is not asking for a preference. They are asking whether you can name the constraints a model has to satisfy, and whether you can tell a real obligation from an inherited habit. The answer starts by refusing the framing: you do not adopt a model, you derive one and then check whether a published shape happens to match it. ## Separate integrating from releasing The most common error is treating one cadence as both. They are different questions: - **Integration frequency** is how often a line of development rejoins the shared mainline and is verified there. It is limited by verification speed and by whether unfinished behaviour can be hidden somewhere other than a branch. - **Release frequency** is how often verified work reaches users. It is limited by approval, contract, customer appetite, regulation or a market window. A team that releases every six weeks is not thereby prevented from integrating every day. Almost always, when a team says otherwise, the underlying blocker is one of two things: it cannot hide unfinished behaviour except on a branch, or it cannot verify the shared line cheaply enough to keep it releasable. Both are solvable, and neither of them is a branching decision. ## The three inputs that actually decide 1. **The release obligation.** Not what the calendar says, but what would break if a release happened tomorrow. Approval, a stabilisation window, a customer notice period, a contractual date with money attached: each is a different constraint with a different remedy. 2. **How many versions live in the field at once.** This is the only input that genuinely forces long-lived parallel lines. If exactly one version is supported and every user is on it, parallel release lines are cost without a matching obligation. 3. **The maturity of automated verification.** Short-lived lines are safe only when the checks gating the mainline are fast and trusted. A team whose checks take hours or fail randomly will batch work regardless of what the diagram says, because people optimise around slow gates. ## A worked decision A nine-engineer car-insurance renewals team ships on a six-week cadence. One contract carries a penalty for missing a delivery date. Two versions are live in the field, because one broker integration has not migrated. The automated checks finish in under 12 minutes and the team trusts them. Derived, not chosen: - Two field versions justify **one** maintenance line for the older version, and only until that broker migrates. The migration date, not the branching model, is the thing to push on. - The six-week cadence justifies nothing at all about branch lifetime. Integration stays daily on one shared line, and unfinished renewal behaviour hides behind runtime switches. - The penalty clause argues *for* short lifetimes rather than against them, because the risk to the date is late discovery, and late discovery is precisely what long-lived lines manufacture. - The stabilisation window shrinks from eleven days to a fixed verification pass, because the shared line was already releasable every day. ## What a constraint justifies, and what it does not | Constraint | Justifies | Does not justify | |---|---|---| | Several supported versions in the field | A maintenance line per supported version, capped | A line per customer or per feature | | A regulated approval step before release | A verified point held for approval | Weeks of unintegrated work while approval runs | | A contractual delivery date | Tight scope control and early integration | Deferring integration until the date is close | | Slow or unreliable automated checks | Investment in the checks themselves | Long-lived lines as a permanent workaround | ## Measure the decision, do not defend it A model is a hypothesis about cost, so instrument it: - **Branch age at integration**, read at a high percentile rather than the median, because the median hides the lines that actually hurt. - **Integration failure rate**, and whether failures cluster near release dates. - **Time from merge to releasable**, which is the honest measure of whether the shared line is really releasable at all. - **Live switch count and age**, because the short end of the axis fails by accumulating switches instead of branches. If those numbers do not move in the direction the decision predicted, the decision was wrong, and saying so a year later is part of owning it. ## Failure modes worth naming - **Adopting a diagram** because a well-known organisation published it, without checking whether its obligations resemble yours. - **Moving to one shared line without making it releasable**, which is the fastest way to convert an integration problem into an everybody-is-blocked problem. - **A line per customer**, which turns a sales concession into an unbounded engineering commitment. - **Treating the cadence as fixed** when the real constraint is an approval step nobody has ever tried to change.