| name | design-branching-strategy |
| description | Use when choosing or designing a Git branching model for a team or project |
| source | Trunk-Based Development (trunkbaseddevelopment.com); "A successful Git branching model" — Vincent Driessen; GitHub Flow docs |
| tags | ["git","branching","trunk-based","gitflow","github-flow","devops"] |
| verified | true |
Design Branching Strategy
Select and configure a Git branching model that matches team size, release cadence, and deployment frequency.
Why This Is Best Practice
Adopted by: Google (mono-trunk), Netflix, Etsy (trunk-based); GitFlow used widely in release-gated software
Impact: DORA research (Accelerate) shows trunk-based development correlates with elite software delivery performance — 46x more frequent deployments, 440x faster lead time.
Why best: The right branching strategy reduces merge conflicts, clarifies code ownership, and aligns version control with deployment processes. Mismatched strategies (e.g., GitFlow for a team deploying daily) create unnecessary overhead.
Steps
- Assess release cadence — Continuous deployment favors trunk-based or GitHub Flow; scheduled releases favor GitFlow.
- — Small teams (<10): GitHub Flow. Medium teams: trunk-based with feature flags. Large/multi-release: GitFlow or release branches.
