Git branching strategies define how development teams organize, merge, and release code within version control systems. These strategies serve as operational blueprints that determine when branches are created, how long they live, who can merge them, and how changes flow from development through testing to production. The right strategy balances team size, deployment frequency, and release complexity — choosing poorly leads to merge conflicts, delayed releases, and deployment risk. While GitFlow dominated the 2010s with its structured multi-branch model, modern teams increasingly favor simpler approaches like GitHub Flow or trunk-based development that align with continuous delivery practices and DORA metrics. Understanding the trade-offs between workflow complexity, integration frequency, and deployment automation is essential for maintaining code quality while shipping features rapidly.
What This Cheat Sheet Covers
This topic spans 16 focused tables and 96 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Workflow Models
These are the primary branching paradigms teams choose between. The right model depends on your release cadence, team size, and CI/CD maturity — and teams often blend elements from multiple models. The industry trend since 2020 is a clear shift away from long-lived branches toward trunk-based approaches as CI/CD tooling matures.
| Model | Example | Description |
|---|---|---|
main branch → feature branches → PR → merge → deploy | • Lightweight workflow with one stable branch and short-lived feature branches • ideal for continuous deployment where main is always deployable. | |
main branch → short-lived branches (<1 day) → frequent merges | • High-velocity model where developers commit to main daily with extremely short-lived branches • requires strong CI/CD and feature flags to maintain stability; used at scale by Google, Netflix, Microsoft. | |
main, develop, feature/*, release/*, hotfix/* | • Structured workflow with multiple long-lived branches for versioned releases • best for projects with scheduled, infrequent releases or multiple production versions. | |
main → pre-production → production environment branches | • Hybrid approach combining GitHub Flow simplicity with environment-specific branches • code flows downstream through staging environments before production. |