Git Branching Strategies: Choose the Right Workflow

Why Branching Strategy Matters

A good branching strategy enables:

• Parallel development
• Code review
• Continuous integration
• Easy releases

Git Flow

Branch Structure

main (production)
  ↑
develop (development)
  ↑
feature/* (new features)
hotfix/* (production fixes)
release/* (release preparation)

Workflow

1. 1main: Production-ready code
2. 2develop: Integration branch for features
3. 3feature/*: New features from develop
4. 4release/*: Release preparation from develop
5. 5hotfix/*: Emergency fixes from main

Commands

bash
# Start feature
git checkout develop
git checkout -b feature/new-feature

# Finish feature
git checkout develop
git merge feature/new-feature

# Start release
git checkout develop
git checkout -b release/1.0.0

# Finish release
git checkout main
git merge release/1.0.0
git tag -a v1.0.0 -m "Release 1.0.0"
git checkout develop
git merge release/1.0.0

# Hotfix
git checkout main
git checkout -b hotfix/critical-bug
# ... fix ...
git checkout main
git merge hotfix/critical-bug
git tag -a v1.0.1 -m "Hotfix 1.0.1"

Pros & Cons

Pros:

• Clear structure
• Organized releases
• Supports parallel development

Cons:

• Complex for small teams
• Long-lived branches
• Merge conflicts

GitHub Flow

Branch Structure

main (always deployable)
  ↑
feature/* (short-lived)

Workflow

1. 1Create branch from main
2. 2Make changes
3. 3Open pull request
4. 4Code review
5. 5Merge to main
6. 6Deploy immediately

Commands

bash
# Create feature branch
git checkout main
git checkout -b feature/add-login

# Make changes and commit
git add .
git commit -m "Add login functionality"

# Push and create PR
git push origin feature/add-login

# After review, merge via PR
# Delete branch
git branch -d feature/add-login

Pros & Cons

Pros:

• Simple
• Continuous deployment
• Short-lived branches
• Easy to understand

Cons:

• Requires good CI/CD
• Frequent deployments
• No staging environment

Trunk-Based Development

Branch Structure

trunk (main)
  ↑
feature/* (very short-lived, < 1 day)

Workflow

1. 1Create short-lived feature branch
2. 2Make changes
3. 3Open PR immediately
4. 4Continuous integration on trunk
5. 5Merge after review (within hours)

Commands

bash
# Create feature branch
git checkout trunk
git checkout -b feature/quick-fix

# Make changes
git commit -am "Quick fix"

# Push PR
git push origin feature/quick-fix

# Merge same day
git checkout trunk
git merge feature/quick-fix
git push

Feature Flags

javascript
// Use feature flags instead of branches
if (featureFlags.isEnabled('new-dashboard')) {
  return <NewDashboard />;
}
return <OldDashboard />;

Pros & Cons

Pros:

• Minimal merge conflicts
• Continuous integration
• Fast feedback
• Simple

Cons:

• Requires feature flags
• High discipline needed
• Good tests required

Choosing the Right Strategy

Use Git Flow if:

• Multiple versions in production
• Scheduled releases
• Large team
• Complex release process

Use GitHub Flow if:

• Continuous deployment
• Web applications
• Small to medium team
• Simple release process

Use Trunk-Based if:

• High-frequency deployments
• Strong CI/CD
• Experienced team
• Feature flags available

Best Practices

1. 1Keep branches short-lived: Merge frequently
2. 2Use pull requests: Enable code review
3. 3Automate testing: CI on every branch
4. 4Delete merged branches: Keep repository clean
5. 5Use branch protection: Protect main branch
6. 6Write good commit messages: Clear history
7. 7Tag releases: Easy version tracking

Branch Protection Rules

yaml
# .github/branch-protection.yml
protected_branches:
  main:
    required_status_checks:
      strict: true
      contexts:
        - CI
    required_pull_request_reviews:
      required_approving_review_count: 1
      dismiss_stale_reviews: true
    enforce_admins: true
    allow_deletions: false

Conclusion

Choose a strategy based on your team size, release frequency, and deployment capabilities. The best strategy is the one your team follows consistently.