Git Flow

Git Flow: The Classic Model

After this page you can name Git Flow’s long-lived branches and when the extra machinery is worth it.

The picture

main          production; tagged releases
develop       next release; features merge here
feat/…        branched from develop, merged back (often --no-ff)
release/x.y   branched from develop, hotfixes, then merge to main *and* develop
hotfix/…      branched from main, merge to main *and* develop

main is always what is in production. develop is the integration line. Features never commit straight to main.

 main     A ─────────────── H1 ── v1.2
            \             ↗
 develop     B ← C ← D ← E ← F
                  \     ↗
 feat/invoices      X ← Y

Commands (shape, not a plugin)

cd ~/desk/desk-api
git switch main
git switch -c develop
git switch -c feat/invoices develop
# … commits …
git switch develop
git merge --no-ff feat/invoices
git branch -d feat/invoices

--no-ff keeps a join node so git log --first-parent develop lists features.

What it costs

Two long-lived branches that diverge. Every hotfix is merged twice. Release branches exist for weeks. For desk-api with one or two people, this is a lot of graph.

What it buys

A support team that must ship 1.2.3 while develop already contains 2.0 work. Multiple versions in the wild. A release manager.

Use Git Flow when you actually have that. The original git-flow CLI is optional; the branch names are the model.

Chapter 31 is how a forge enforces this (protected main, required PRs). This page is the topology.