Choosing the right Git branching strategy shapes how fast your team ships and how painful merges are. We compare trunk-based development and Gitflow, with guidance on which suits your team.

# Git Workflows for Teams: Trunk-Based vs. Gitflow Your branching strategy is a fundamental team decision. It affects release cadence, merge pain, CI/CD pipeline design, and how quickly you can fix production bugs. ## Gitflow Gitflow uses long-lived branches: - `main` – production-ready code - `develop` – integration branch - `feature/*` – individual features - `release/*` – release prep - `hotfix/*` – urgent production fixes **Pros:** Clear structure; good for versioned software with scheduled releases. **Cons:** Long-lived branches cause merge hell; slows continuous delivery. ## Trunk-Based Development (TBD) Everyone commits to `main` (trunk) frequently—ideally multiple times per day. Feature flags control what users see. ```bash # Short-lived feature branch (< 2 days) git checkout -b feat/add-payment-method # ... work ... git push origin feat/add-payment-method # Open PR → review → merge to main same day ``` **Pros:** Eliminates merge conflicts; enables true CI/CD; forces small, reviewable commits. **Cons:** Requires discipline, feature flags, and solid test coverage. ## Which Should You Choose? | Factor | Gitflow | Trunk-Based | |---|---|---| | Release cadence | Scheduled (monthly/quarterly) | Continuous | | Team size | Works at any size | Works best with CI culture | | Merge conflicts | Frequent | Rare | | Feature flags needed | No | Yes | **Recommendation:** Default to trunk-based for web services. Reserve Gitflow for libraries or products with hard versioned releases. ## Getting Started with TBD 1. Keep branches alive for < 2 days. 2. Use feature flags (LaunchDarkly, Unleash) for in-progress work. 3. Write tests before merging. 4. Automate CI on every push to main. The best workflow is the one your team actually follows consistently.