Collaboration Patterns

Trunk-based vs GitFlow — choosing the right workflow for your team's release cadence and velocity

Why

How a team uses git determines how fast they can ship, how painful their merges are, and how easy it is to hotfix production. There's no universally correct workflow — the right choice depends on release cadence, team size, and CI maturity, and thinking beyond mechanical git use is what separates senior engineers.

Intuition

The core tension: long-lived feature branches avoid merge conflicts in the short term but create much larger ones later — "merge hell." Trunk-based development forces small, frequent integrations that keep conflicts small and surface integration issues early. The longer a branch lives, the more it diverges, and the harder it is to merge.

Explanation
Trunk-based vs GitFlow
Trunk-based development
Everyone integrates to main frequently — multiple times per day. Branches are short-lived (1–2 days max). Requires strong CI and feature flags for incomplete work. Used by high-velocity SaaS teams, Google, Facebook.
GitFlow
Long-lived feature branches, a develop integration branch, release branches, and hotfix branches. More ceremony but better for versioned software with scheduled releases. Harder to maintain for teams shipping continuously.
Feature flags and fork workflow
# Feature flags: merge incomplete code but gate who sees it in prod # - unfinished features go to main behind a disabled flag # - flag rolled out to % of users (canary) or specific groups # - enables trunk-based development without half-baked prod features # Fork workflow (open source contribution): # 1. Fork the repo to your own account on GitHub # 2. Clone your fork → create branch → commit → push to your fork # 3. Open PR from your fork's branch → upstream main # Not needed for private team repos — branch workflow is simpler