Choosing Your Strategy

Strip the buzzwords and every branching strategy is built from three moves.

CUT - open a line off an existing one. A branch is a 41-byte name; cutting is free.

LAND - merge the line back where its work belongs.

MARK - stamp a moment you shipped: a tag, usually on main.

Four famous strategies are just four answers to WHERE you cut, how LONG the line lives, and where it LANDS.

GitHub Flow: one long line, many short visits. main is always releasable. Every change - feature or fix - cuts a short branch, opens a PR, lands back on main, and deploys. No develop, no release lines: the strategy IS the PR loop you already know. It shines when you can ship any day; it strains when many versions must be supported at once, because there is only one line to support from.

Trunk-based: everyone lands on main, daily. Teams here CHOOSE to keep branches short - often merged the same day; some commit straight to the trunk. Half-done work hides behind feature flags instead of long branches. The trade is discipline for speed: merges stay tiny so conflicts stay tiny, but you need real tests and real flags. This is what Git Flow's own author points continuous-delivery teams toward.

Git Flow: five lanes with fixed jobs. main holds releases only; develop collects finished work; feature, release and hotfix lanes open for one job and close. Every route is fixed - a release hardens on its own lane and lands on BOTH main and develop; a hotfix cuts from main and also lands back on both. Heavy, but legible: on a long-lived versioned product you can read the graph and know the world.

Release branching: keep the versions you must support. Cut a line per shipped version (1.x, 2.x) and let it live as long as customers run it. The one law that keeps it sane: a fix lands on main FIRST, then a copy travels back to the release line (cherry-pick, NEW id). Fix on the old line first and you will forget to forward-port - the bug returns in the next version wearing a new coat.

Stabilization flow: bugfix vs hotfix. When a release line hardens, fixes found PRE-ship are bugfixes (born on the release line); fixes found in PRODUCTION are hotfixes (born from the shipped mark). Both forward-merge to main - the full drawing is on the next card. (No contradiction with the point above: while a release HARDENS pre-ship, fixes are born ON it; once a line has shipped and lives long-term, the main-first law takes over.)

The decision rule, whole chapter in one breath.

Ship any day, support only the latest? GitHub Flow - or trunk-based when flags and tests are real.

Several shipped versions to support? Release branches + the main-first law.

Audited, versioned, fixed ceremony? The one home where Git Flow earns its weight.

Start with the lightest strategy that answers your support question - adding lanes is easy; removing them is the hard part.