Modern Git Workflows: Trunk-Based vs GitFlow vs Stacked Diffs

The branching strategy you choose shapes how often you ship, how risky each release is, and how much time engineers spend resolving conflicts.

1. Trunk-Based Development

• One long-lived branch (main).
• Short-lived feature branches (hours, not days).
• Feature flags hide unfinished work.

Best for: small teams, continuous deployment, mature CI/CD.

Pros: tiny merges, fast feedback, no merge conflicts. Cons: requires solid test coverage and feature flag tooling.

2. GitFlow

• main, develop, feature/*, release/*, hotfix/*.
• Releases cut from develop to a release/x.y branch, then merged to both.

Best for: shipped software (desktop, mobile, embedded) with versioned releases.

Pros: clear release cadence, easy hotfixes against any version. Cons: lots of branches, frequent merge pain, slower than CI/CD models.

3. Stacked Diffs

• One commit per logical change.
• Each commit becomes one PR; PRs depend on each other.
• Tools: Graphite, Sapling, git-spice, Phabricator.

Best for: large monorepos, fast reviewers, infra changes that touch many layers.

Pros: small focused reviews, parallel work, atomic rollbacks. Cons: tooling overhead, not native to GitHub UI.

How to pick

Factor	Trunk-Based	GitFlow	Stacked
Deploys per day	dozens	weekly+	dozens
Versioned releases	rare	yes	rare
Team size	small/medium	any	medium/large
Review culture	trust + flags	gated	rapid + tooling

Hybrid is fine

Most teams end up with trunk-based + release tags + occasional hotfix branches. Pick the simplest workflow your release model can tolerate.