Tags: web-dev concept

Branching Strategies

Date: 2026-08-17

---

How a team arranges work in branches, and how long those branches live. The choice is really about release cadence — a strategy designed for versioned quarterly releases makes continuous deployment painful, and vice versa.

---

A branching strategy defines which branches exist, what each is for, how work flows between them, and how long a branch lives before merging.

Branch lifetime is the variable that matters. Everything else follows from it.

The three that cover practice

Trunk-based development — everyone commits to one branch, main, with branches living hours rather than days.

• Continuous integration in the literal sense — Continuous Integration
• Requires feature flags for anything incomplete — Feature Flags
• Requires strong automated tests, because main must always be releasable
• The only strategy that genuinely supports continuous deployment

GitHub flow — main is always deployable, work happens on short-lived branches merged via pull request.

• The pragmatic middle, and the most common in web teams
• Branches live days, not hours
• Deploy from main after merge

Git flow — main, develop, and feature, release and hotfix branches.

• Designed for versioned software with scheduled releases — desktop applications, libraries, anything a customer installs
• Heavy for a continuously-deployed website, and frequently adopted anyway
• Its author has since noted it isn’t intended for continuous delivery

The comparison

	Trunk-based	GitHub flow	Git flow
Long-lived branches	None	None	develop, releases
Branch lifetime	Hours	Days	Weeks
Suits	Continuous deployment	Continuous deployment	Scheduled releases
Needs feature flags	Yes	Sometimes	No
Merge conflict risk	Lowest	Low	Highest
Ceremony	Least	Little	Most

Long branches are the actual problem

Every day a branch lives, it diverges further from main, and the cost of merging grows non-linearly — the conflicts interact.

day 1    3 files changed on both sides
day 5    18 files, and some of yours
         depend on code someone else
         has since deleted
day 20   a merge nobody wants to review,
         landing all at once

A three-week branch is a three-week-delayed integration, which is precisely what continuous integration exists to prevent. The strategy is largely a mechanism for keeping branches short.

What makes short branches possible

You can’t shorten branches by instruction — the enablers have to exist first:

• Feature flags, so incomplete work can merge without being visible — Feature Flags
• A fast, trustworthy test suite, or merging often is terrifying — Flaky Tests
• Small pull requests, which get reviewed in hours rather than days — Code Review
• The expand–contract pattern for anything with a schema or an API — Backwards Compatibility

Feature flags are the enabling technology for trunk-based development. Without them, incomplete work has nowhere to live except a long branch.

Release branches, where they’re still right

Legitimate cases for a longer-lived branch:

• Supporting an old version for customers who haven’t upgraded
• A regulated release requiring a frozen, audited artefact
• Hardware or mobile app store cycles, where release timing isn’t yours

For a continuously-deployed website, none of these apply — which is why git flow’s ceremony usually buys nothing there.

Choosing

Work back from how often you ship:

• Several times a day → trunk-based, with flags
• Daily or weekly → GitHub flow
• Scheduled versioned releases → git flow or a release-branch model

Then check the branch lifetimes actually match. A team nominally on GitHub flow with three-week branches has git flow’s cost and none of its structure — and that mismatch is more common than any strategy.