Which Git branching model fits a team deploying to production several times a day, and why?

## The question behind the question An interviewer asking this is not testing whether you can recite branch names. They want to see that you pick a branching model from a property of the product, and that you can say what the Git-level cost of the wrong choice is. ## The variable that decides it The deciding property is **how many versions of the software are live at once**, which follows from the deploy model. If you operate the software yourself and there is exactly one production version at any moment, there is exactly one line of history that needs to exist forever. Everything else is a temporary branch. If customers run copies of your software and several released versions are supported simultaneously, you need somewhere to keep committing per version — a branch per release line. That is a structural need no tag can satisfy, and it is what Git Flow and GitLab Flow's release-branch variant provide. Release cadence is the second variable. Discrete, scheduled releases give a stabilization period a release branch can occupy. Continuous deployment has no such period. ## Several deploys a day: what the models cost At that cadence, walk through Git Flow's branch set and ask what each one is holding. `develop` holds work that is finished but unreleased. If you release hourly, that set is nearly empty. What you get instead is a second permanent branch that can diverge from `main`, and every fix that must exist on both has to be merged twice. The classic incident — a hotfix merged into `main` but forgotten on `develop`, reintroduced by the next release — is a pure tax with no matching benefit. A release branch holds stabilization commits while feature work continues on `develop`. Cut and deleted the same day, it holds nothing; the parallel feature work it protects against amounts to a few hours. A hotfix branch exists so a production patch can avoid unreleased work. If `main` is deployed continuously, there is no unreleased work to avoid; the fix is just another short topic branch. So the answer is a single long-lived `main`, with short-lived branches created from its tip and merged straight back — the GitHub Flow shape. ## Why short branches are the operative part A three-way merge diffs both sides against their merge base. The further back the merge base, the more unrelated change is in each diff and the more likely two edits collide. Branch lifetime is therefore the main input to conflict pain, and it is the thing this model actually controls: cut from `origin/main`, merge back within a day or two, bring `main` in while you work. The divergence is measurable rather than a matter of opinion. `git rev-list --left-right --count main...develop` prints how many commits each side has that the other lacks. If that number is small and stays small, the second branch is not doing anything. `git for-each-ref --sort=-committerdate refs/heads/` shows how stale the branch tips are, which tells you whether "short-lived" is true in practice or only in the team's self-description. ## Where the heavier models still win A library, a desktop application, an on-premises product: users are on 2.3 while you are building 3.0, and 2.3 needs a patch. You need a branch sitting on the 2.3 line. Cut it once and keep it; that is Git Flow's release branch, or the per-version branch of GitLab Flow's release variant. A gated deploy pipeline, where staging deliberately lags production or a promotion is a manual decision, is the case for GitLab Flow's environment branches: the branch encodes real information about where code is running. ## What marks a release without a branch If you drop release branches you still need to name versions. An annotated tag on a commit of `main` does that, and `git describe` then expresses any later commit relative to the nearest tag. The information is preserved; only the structure is dropped. ## How to answer without sounding dogmatic Name the model, name the property that decided it, and name what you gave up. "Single main with short branches, because we run one version and deploy continuously — which means we lose the stabilization window a release branch would give us, and we pay for that with the discipline of keeping main deployable." That is a judgment, not a preference, and it is what the level is being tested for. The strongest supporting fact you can cite: the author of Git Flow later appended a note to the original article steering continuously delivered web applications toward simpler models, while standing behind it for versioned, shipped software. The model was never wrong; it was designed for a different release shape.