Branching Strategies
How Teams Organize Branches
You've now used branches, merges, and even push/pull with a remote. This section zooms out: given those same building blocks, how do real teams organize dozens of people's branches so nothing collides? There's no single "right" way - teams pick a strategy that fits how often they release.
| Strategy | Idea | Best for |
|---|---|---|
| GitHub Flow | One main (always deployable) + short-lived feature branches → PR → merge | Continuous deployment, web apps |
| Trunk-Based | Everyone commits to main ("trunk") frequently, often behind feature flags that hide unfinished work | High-velocity teams, CI/CD |
| Git Flow | Long-lived develop and main, plus temporary feature/, release/, hotfix/ branches for each stage | Scheduled releases, versioned software shipped to customers |
Analogy: GitHub Flow is a busy kitchen where each dish (feature) is cooked on its own station and served the moment it's ready. Git Flow is a formal restaurant with dedicated prep, plating, and release stages - more structure and ceremony, but more predictable for large, versioned releases.
Tip: Most modern web teams use GitHub Flow or trunk-based development - small branches, fast merges, deploy often, and main is always safe to ship. Git Flow shines instead when you ship discrete versioned releases (v1.2, v1.3) to customers who upgrade on their own schedule and might run several versions at once - think desktop software or a mobile app, not a website that redeploys constantly.