Branching Strategies

Why it matters

Teams need consistent rules for branching. The right strategy depends on team size, release frequency, and deployment model.

Key concepts

• Git Flow — Complex branching with main, develop, feature, release, hotfix
• GitHub Flow — Simple model: main + feature branches + PRs
• Trunk-Based — Everyone commits to main with short-lived branches
• Feature Flags — Toggle features on/off without branching

The idea

Three Philosophies

Git Flow: For scheduled releases (e.g., mobile apps, enterprise software)

• Many long-lived branches
• Formal release process
• Complex but controlled

GitHub Flow: For continuous deployment (e.g., web apps)

• Main is always deployable
• Feature branches, PRs, merge, deploy
• Simple and fast

Trunk-Based: For high-velocity teams (e.g., Google, Facebook)

• Everyone commits to main
• Short-lived branches (hours, not days)
• Requires excellent CI/CD

Walkthrough

Git Flow

main (production)     ────●────────────────────●────────►
                          ↑                    ↑
hotfix                    │    ●───●           │
                          │        ↓           │
release                   │    ●───●───●───────│
                          ↑        ↑           ↑
develop              ─────●────●───●───●───────●────────►
                              ↑       ↑
feature/a                ●────●       │
feature/b                    ●────────●

Branches:

• main: Production releases only
• develop: Integration branch
• feature/*: New features (from develop)
• release/*: Release preparation
• hotfix/*: Emergency production fixes

GitHub Flow

main (always deployable) ────●────●────●────●────●────►
                              ↑    ↑    ↑    ↑
feature branches         ●────●    │    │    │
                              ●────●    │    │
                                   ●────●    │
                                        ●────●

Rules:

1. Main is always deployable
2. Branch from main for all changes
3. Open PR for discussion
4. Deploy from branch (optional)
5. Merge after review

Trunk-Based Development

main ────●────●────●────●────●────●────●────●────►
          ↑    ↑    ↑    ↑
         (short-lived feature branches, <1 day)

Requirements:

• Strong CI/CD pipeline
• Feature flags for incomplete features
• High test coverage
• Small, frequent commits

Comparison

Aspect	Git Flow	GitHub Flow	Trunk-Based
Complexity	High	Low	Medium
Release cadence	Scheduled	Continuous	Continuous
Branch lifespan	Long	Days	Hours
Best for	Versioned releases	Web apps	High-velocity teams

Key takeaways

• Git Flow for scheduled releases
• GitHub Flow for continuous deployment
• Trunk-Based for high-velocity teams
• Match strategy to release model

Dos & don’ts

✅ DO

• Document your strategy: Team should agree on conventions
• Automate what you can: CI/CD reduces human error
• Keep branches short-lived: Long branches = merge pain
• Review before merge: Quality gate is essential

❌ DON’T

• Don’t mix strategies: Pick one and stick with it
• Don’t skip CI: Breaking main is expensive
• Don’t create branch chaos: Follow naming conventions

Going deeper

Release Branches: Git Flow’s release branches allow stabilization while develop continues. Useful for products with support windows (v1.x vs v2.x).

Feature Flags: Alternative to branching—deploy incomplete code with flags off. Enables trunk-based development without breaking production.

Common mistakes

Long-lived feature branches: The longer a branch lives, the harder merging becomes. If it’s taking weeks, split the feature into smaller pieces.

Develop branch rot: In Git Flow, if develop gets too far ahead of main, release merges become painful. Do regular releases to keep them synchronized.