What single axis separates branching models, and why does it decide everything else?

## The axis A branching model is usually presented as a diagram of named lines with rules about who merges into what. That presentation hides the only variable that matters. Take any two models, strip the names, and ask one question: **how long does a line of development live away from the shared mainline before its work is integrated?** Hours? A day? Six weeks? That number predicts almost everything else the model has to say. It predicts the overlap profile, the shape of the release process, what has to be automated, who has to own reconciliation, and what unfinished work does while it waits. It also predicts how the model fails when it fails. ## Divergence does not add up, it compounds Two changes that overlap for one day are reconciled by looking at a handful of lines. The same two changes overlapping for six weeks are a different kind of problem, for three separate reasons: - **Textual overlap grows.** More edits touching more files means more places where two histories both claim a region of the same file. - **Semantic drift grows faster.** A version-control merge reconciles text. It cannot see that one line renamed a concept the other line built on, or that both lines implemented the same rounding rule differently. That class of problem is invisible to the merge and surfaces only once both are integrated and the tests run. - **The number of pairs grows.** Divergence is not only between one line and the mainline; it is between every pair of open lines that will eventually meet. Four lines open for a week are six pairs to reconcile. This is why teams describe integration after a long divergence as an event rather than a step: an integration week, a stabilisation phase, a merge nobody wants to own. The work did not appear at merge time. It accumulated the whole time, unpriced, and merge time is when the bill arrives. A nine-engineer car-insurance renewals team on a six-week release cadence hit this exactly. A line of development kept alive for 41 days came back with only three files overlapping textually, and those took an afternoon. What took eleven days was that the renewal-price rule had been rewritten on both lines with different rounding at the boundary. Nothing conflicted. Everything disagreed. ## What each end of the axis demands | | Short-lived lines, continuous integration | Long-lived parallel lines | |---|---|---| | Typical lifetime | Hours to a day | Weeks to months | | Where unfinished work hides | Behind a runtime switch | On the line itself | | When you pay | A little, every day | Once, at integration | | Prerequisites | Fast, trusted automated checks; a mainline kept releasable | An integration phase, a stabilisation window, an owner for reconciliation | | Characteristic failure | A broken mainline blocks everyone at once | Design drift discovered late, near a release date | Neither column is virtue. The table is a price list. A team choosing the right column has decided which of those failures it can absorb and which prerequisites it can actually meet. ## The shapes have names, and the names matter less The recognisable models are points on this axis. A model with long-lived parallel release and development lines plus a formal integration path is commonly labelled Git Flow; the single-shared-line variant, where each short-lived change line goes straight back to the mainline after review, is commonly labelled GitHub Flow; **trunk-based development** is the name for driving the lifetime down to roughly a day. Recognise the labels, then argue about lifetime, because two teams following the same named diagram can sit six weeks apart on the axis that decides their pain. ## What integrated actually means One trap deserves naming. A change is not integrated because it was merged. It is integrated when the shared line, with that change in it, has been verified by the automated checks the team trusts. A merge that lands and then sits unverified for a day is divergence that has only changed hiding place. That is why the short end of the axis is impossible without fast, trustworthy verification: the model does not fail politely, it fails by putting an unverified mainline underneath everyone at once. ## Using the axis in an interview Do not answer with a diagram. Say what you are optimising, then place the team on the axis: how long lines live now, why they live that long, what would have to be true for them to live a day, and which of those things the team is missing. That answer works for a model you have never heard of, which is the point.