Git Branching Strategies: Trunk-Based vs Git Flow
Key takeaway
Trunk-based development with short-lived branches is the right default for teams deploying continuously, and it requires solid automated tests and feature flags. Git Flow's release and hotfix branches earn their complexity only when you must support multiple released versions in the wild.
Branching strategy arguments are really arguments about how often you can safely release. Pick the model that matches your release reality, not the one with the best diagram.
The main options
- Trunk-based — everyone commits to one main branch, via branches that live hours to a couple of days. Unfinished work hides behind feature flags. Requires good automated tests.
- GitHub flow — a branch per change, a pull request, merge and deploy. Trunk-based in practice for most teams, with review built in.
- Git Flow — long-lived develop and main branches, plus release and hotfix branches. Designed for versioned software with scheduled releases.
- Release branches — a cut taken per version and maintained separately. Necessary when customers run versions you must patch.
Why long-lived branches hurt
The cost of a branch grows with its age. A branch open for three weeks accumulates conflicts, hides work from the test suite, and produces the merge that nobody wants to review properly. Most "we need a better branching strategy" conversations are actually about branches living too long — and the fix is smaller changes, not more branches.
Choosing
- Deploying multiple times a week, one version in production, decent test coverage: trunk-based or GitHub flow.
- Scheduled releases with a QA cycle, or regulatory sign-off before release: a release branch is justified.
- Customers running several versions you must support: you need maintenance branches, and Git Flow's structure starts to make sense.
- Mobile apps: release branches are effectively mandatory, because a shipped build can't be recalled and a hotfix must be cut from what was released.
Practices that matter more than the model
- Keep changes small — a pull request that takes an hour to review gets reviewed properly; one that takes a day gets approved.
- Protect the main branch: required checks, required review, no direct pushes.
- Keep main deployable at all times. If it isn't, nothing else in the process works.
- Tag releases and keep a changelog; when an incident starts, the first question is what changed.
- Write the rule down. Most branching problems are people following three different conventions, not the convention being wrong.