Principle: Trunk-based development over long-lived branches

Long-lived feature branches diverge from main, causing painful merges, delayed integration, and hidden conflicts.

Trunk-based development in practice:

TRUNK-BASED DEVELOPMENT:
- All developers commit to main (trunk) daily
- Feature branches live < 2 days
- Merge/rebase frequently from main
- Deploy from main continuously

VS. GITFLOW:
- Long-lived develop + feature branches
- Weeks between merges
- Complex release process
- High merge conflict risk

How to make short-lived branches work:

1. Feature flags (deploy code, toggle feature)

   if (featureFlags.newCheckout) {
     renderNewCheckout();
   } else {
     renderOldCheckout();
   }
   

- Merge incomplete features behind flag
- Test in production with limited users
- Roll back without deploy

1. Branch by abstraction (for large refactors)

- Create abstraction layer
- Implement new version behind abstraction
- Switch over, remove old code
- All on main, no long-lived branch

1. Small PRs (< 200 lines changed)

- Easier to review
- Faster to merge
- Lower conflict risk
- Break large features into small increments

1. CI/CD pipeline

- Automated tests on every commit
- Automated deploy on merge to main
- Fast feedback (< 10 min build)

When long branches are OK:

• Major version upgrades (React 17->18)
• Database migrations requiring downtime
• Truly experimental R&D work

Even then: Merge main INTO the branch daily to reduce final merge pain.

Google, Facebook, and Netflix all practice trunk-based development. Integration pain is proportional to branch lifetime. Daily integration = minimal pain.

Git branching strategy