Branching Strategies

The plain-language idea

A branching strategy is just a team's agreed answer to one question: how long does a branch live before it merges back, and what has to happen before it does? That single decision cascades into how often you integrate, how big your merge conflicts get, and how fast a fix reaches production. Three strategies dominate real teams:

Git-flow is the oldest and heaviest. It formalizes multiple long-lived branches: main holds only released code, develop is the integration branch, feature/* branches fork from develop and merge back into it, and release/* branches stabilize a version before it becomes a tagged commit on main. It also has hotfix/* branches that patch main directly and get merged back into both main and develop. It was designed for software with scheduled, versioned releases — think desktop apps shipping v2.3, v2.4.

GitHub flow strips that down to one long-lived branch, main, which is always deployable. Everything else is a short-lived feature branch that forks from main, gets a pull request, gets reviewed, and merges straight back into main — no develop, no release branch. It assumes you can deploy main continuously, which fits web apps and services far better than versioned desktop software.

Trunk-based development goes further still: branches (if they exist at all) live hours, not days. Developers commit directly to main — or to branches so short they're barely branches — behind feature flags, so incomplete work ships to production dark and gets turned on later. Integration happens constantly instead of in batches.

The tradeoff underneath all three is the same one: the longer a branch lives apart from main, the more main drifts out from under it, and the uglier the eventual merge conflict. Git-flow's develop branch can be weeks stale relative to main's hotfixes. Trunk-based development makes that drift structurally impossible by never letting it accumulate. That's the real reason most modern teams have moved toward GitHub flow or trunk-based: not fashion, but that CI/CD made "deploy constantly" achievable, which removed git-flow's whole reason for existing — coordinating rare, big-batch releases.

See it in a real thing: the same fix, three strategies

A critical bug fix, in each model:

Git-flow:

$ git checkout -b hotfix/login-crash main
# fix, commit
$ git checkout main && git merge hotfix/login-crash
$ git checkout develop && git merge hotfix/login-crash
$ git tag v2.4.1

Two merges, because the fix has to land in both branches that track "current state."

GitHub flow:

$ git checkout -b fix/login-crash main
# fix, commit, push
$ gh pr create --base main
# review, then merge — main is deployed

One branch, one PR, one merge. main was already deployable, so merging it is shipping it.

Trunk-based:

$ git checkout main && git pull
# fix, commit directly (or a branch that lives under an hour)
$ git push origin main

No PR ceremony assumed (though many trunk-based teams still use short-lived PRs) — the fix is live within minutes, often wrapped in a feature flag if it touches anything user-facing that isn't fully tested yet.

Trunk-based development: one main line. Branches are short-lived — created, worked on for hours, and merged straight back into main.

BackNext

What people usually miss

Watch out

• Git-flow isn't "wrong," it's scoped to a problem most web teams no longer have. If you genuinely ship versioned releases on a schedule (embedded firmware, installed desktop software, libraries with semver consumers), git-flow's structure still earns its complexity. The mismatch is using it for a service you deploy on every merge.
• "Trunk-based" doesn't mean "no branches, no review." Most trunk-based teams still use branches — they're just hours-long, not weeks-long, and often still go through a lightweight PR. The defining trait is short-lived integration, not the absence of branching or review.
• GitHub flow assumes main is always releasable. That's a discipline, not a default — it requires CI gating every merge (tests, lint, build) so a broken main is rare enough that "deployable" stays true in practice, not just in name.

The genealogy: this is a merge-conflict cost curve

Every strategy here is really a policy about branch lifetime, and branch lifetime is what this track's earlier lesson on merge conflicts identified as the actual variable that predicts conflict pain — divergence between two histories, not "how many people touched the file." Trunk-based development is the logical end of minimizing that variable; git-flow is what you get when you accept it in exchange for release control.