Git Branching Strategies: GitHub Flow vs Trunk-Based Development

A branching strategy is an agreement about how work flows into the main branch and out to users. The trend in recent years has been towards fewer, shorter-lived branches.

GitHub Flow

1. main is always deployable.
2. Create a branch for each change.
3. Open a pull request, get a review, pass CI.
4. Merge to main and deploy.

Simple and popular for web apps and services that deploy continuously.

Trunk-based development

Everyone integrates into the main branch (the trunk) at least daily, using very short-lived branches or direct commits. Unfinished features hide behind feature flags:

if (flags.isEnabled('new-checkout', user)) {
  return renderNewCheckout();
}
return renderCheckout();

• Avoids long-lived branches and painful merges.
• Requires strong automated tests and fast CI.
• Lets you deploy code before releasing the feature, and turn it off without a deploy.

Git Flow

Long-lived develop and main branches, plus feature, release and hotfix branches. It suits software with scheduled, versioned releases (mobile apps, installed products), but adds overhead that continuous-delivery teams usually don't need.

Choosing

• Web apps and APIs deploying often: GitHub Flow or trunk-based.
• Multiple supported versions in the field: release branches (Git Flow or a lighter variant).
• Whatever you choose, keep branches short-lived. A branch older than a few days is a merge conflict waiting to happen.

Protect main

Use branch protection or rulesets: require pull requests, passing checks and up-to-date branches before merging.