In Git, which branches does the Git Flow model define and what is each one for?

## What Git Flow actually is Git Flow is a branching model published by Vincent Driessen in 2010. Git itself knows nothing about it: every branch below is an ordinary Git branch — a movable pointer to a commit — and the model is a naming convention plus rules about where a branch starts and where it merges back. There is an optional third-party helper script invoked as `git flow`, distributed separately from Git, but the whole model works with nothing but `git branch`, `git merge` and `git tag`. ## The two permanent branches **main** (called `master` in the original article) contains only code that has been released. Each commit on it corresponds to a shipped version and is normally marked with an annotated tag. No one commits to `main` directly; commits arrive only by merging a release branch or a hotfix branch. **develop** is the integration branch. Finished features accumulate there between releases, so its tip means "the next release, so far". Day-to-day work in a Git Flow repository starts from `develop`, not from `main`. Because both branches live forever, they permanently diverge and re-converge. `git log main..develop` almost always lists commits — that is the model working as designed, not a problem to fix. ## The three supporting branch types **Feature branches** start from `develop` and merge back into `develop`, conventionally named `feature/<something>`. Work on a feature branch never touches `main` directly. **Release branches** are cut from `develop` once the team fixes the scope of the next version, conventionally `release/1.4.0`. Only stabilization commits belong there — bug fixes, version bumps, changelog edits — while new features keep landing on `develop` in parallel. When the version ships, the release branch merges into `main` (which is then tagged) and back into `develop`, and is deleted. **Hotfix branches** start from `main`, not from `develop`, because they fix what is running in production right now, and unreleased work on `develop` must not be dragged along. Conventionally `hotfix/1.4.1`. They merge into `main`, which is tagged again, and into `develop`. ## Why releases and hotfixes merge in two directions This double merge is the structural heart of the model. `main` and `develop` are different lines of history; a commit merged into one is not present in the other. If a hotfix landed only on `main`, the next release branch — cut from `develop` — would not contain the fix, and shipping it would reintroduce the very bug that was just patched in production. Merging the hotfix into `develop` as well makes the fix an ancestor of both lines, so later merges treat it as already integrated instead of as a conflicting change. The same argument applies to a release branch: stabilization commits made on it must travel back to `develop`, or they are lost at the next release. ## What Git does at each step Every step is a plain three-way merge, using the commit where the branch diverged as the merge base. Git Flow conventionally uses `git merge --no-ff`, which records a merge commit even when the target could simply fast-forward. The effect is that each feature shows up in history as one merge commit with its own commits on a side branch, so `git log --first-parent develop` reads as a list of features rather than a flat stream of individual commits. Deleting a feature or release branch after the merge loses nothing. The commits remain reachable through the merge commit; only the pointer disappears. ## Where the model fits Git Flow was designed for software with explicit, versioned releases — desktop applications, libraries, on-premises products, anything where several versions exist in the field at once. The release branch gives a place to stabilize while feature work continues; the hotfix branch gives a way to patch what shipped without shipping anything unreleased. It fits a service deployed many times a day badly: `develop` is then never meaningfully ahead of `main`, and every change pays for a second merge and a branch that exists for minutes. Driessen later added a reflection note to the original article steering continuously delivered web applications toward simpler, single-main workflows. ## The vocabulary trap Being able to say that `git flow` (the helper script) and Git Flow (the model) are different things — and that Git ships neither — is what separates someone who understands the model from someone who has memorized a tool's menu.