Branching strategies: Git Flow, GitHub Flow, trunk-based

A branching strategy is a decision about where work integrates and when. The brand names — Git Flow, GitHub Flow, trunk-based — are convenient shorthand, but the actual choice is driven by your release model: continuous deployment to web users, versioned releases to customers, or something in between.

Pick the strategy that matches the release shape. The teams who suffer most are the ones running Git Flow because “it’s the standard” while shipping to production every hour.

The three models side by side

Git Flow

Originally described by Vincent Driessen in 2010. Two long-lived branches and three supporting branch types.

Rules. Feature branches off develop, merged back into develop. Release branches off develop when ready to ship, merged into both main and develop after release prep (version bump, last fixes). Hotfix branches off main, merged into both main and develop. Every merge uses --no-ff to preserve the branch shape in history.

The author’s own 2020 critique. Driessen later acknowledged that Git Flow was designed for “software with explicit versioning and multiple supported versions in production” — desktop apps, libraries, embedded products. For continuously-deployed web applications, he recommends GitHub Flow instead. The model wasn’t wrong; it was just applied outside its intended context.

Fits when: you ship versioned releases to customers; you maintain multiple production versions in parallel; releases involve a real preparation phase (changelogs, regulatory review, customer comms).

Doesn’t fit when: you ship multiple times per day to one production environment.

GitHub Flow

A simpler model from GitHub, popularised around 2011. One long-lived branch, short-lived feature branches, deploy from main.

1. Branch off `main`

   Descriptive branch name. The branch’s lifetime is measured in days, not weeks.

2. Commit and push

   Small, focused commits. Push early to make the branch visible.

3. Open a pull request

   Often before the work is done — drafts invite early feedback.

4. Review, address, repeat

   Reviewers leave comments; author pushes additional commits to the same branch.

5. Merge to `main`, deploy

   Once approved and CI passes. Many teams deploy main automatically on every merge.

6. Delete the branch

   Closes the loop. The PR retains the history.

Fits when: you ship continuously (or want to); the team is small enough that PR review is the primary quality gate; your CI catches most regressions before merge.

Doesn’t fit when: you have parallel supported releases (no obvious place for hotfix branches against older versions); strict compliance requires a designated release artifact distinct from main.

Trunk-based development

Everyone commits to a single branch (“trunk” or main). Feature branches, if they exist at all, live for hours — long enough for CI and code review on a single change, then gone.

The two flavours. Small teams may commit directly to trunk multiple times daily. Larger teams use very short-lived feature branches (one developer, one change, one CI run, then merge). Either way, the branch isn’t a place where work accumulates — it’s a place where one change is reviewed.

Feature flags are non-negotiable at scale. If you commit incomplete features to trunk, you must be able to deploy the code while keeping the feature dark to users. Without flags, trunk-based development collapses into “everyone breaks main on Tuesdays.”

Branch by abstraction for big refactors. Long-running structural changes are not done on a long branch — they’re done as a sequence of small commits to trunk, each preserving the existing behaviour, until the new path is ready and the old can be removed.

Scale evidence. Google runs trunk-based development at ~35,000 developers in a single monorepo. The investment in build infrastructure, test selection, and flagging that enables this is non-trivial — but it’s the only model that has demonstrably scaled to that size.

Fits when: continuous integration is a hard requirement; the team has invested in feature flags; build/test infrastructure can keep trunk green.

Doesn’t fit when: feature flags are not in the toolkit; CI is slow or unreliable; releases are versioned and require a stable cut-point.

Picking one

Layered workflows on top of branching

A branching strategy is the shape of where work goes. On top of that shape, teams layer practices that change how work moves through it:

• Protected branches with required reviews and CI. Available in every modern host. Pairs with all three strategies.
• Merge queues. Linearise merges to avoid the “green PR + green PR = red main” race. Especially valuable for trunk-based at scale.
• Stacked diffs. Smaller review units within whichever strategy you’ve picked. Particularly natural inside GitHub Flow and trunk-based. See 0029 Stacked diffs: commits as review units · Git .
• Safe-merge / pre-merge integration. Some platforms (e.g. JetBrains Space) materialise a speculative merge with main and run CI on it before final merge — catches drift conflicts that ordinary CI misses.

The branching strategy and the layered practices are separable decisions. Don’t conflate “we use GitHub Flow” with “we don’t have a merge queue.”

Anti-patterns

References

• Vincent Driessen, A successful Git branching model (2010, with 2020 author’s note recommending against it for web apps).
• GitHub Docs, GitHub Flow.
• Trunk-based development — practices and scale evidence at trunkbaseddevelopment.com.