Branching Strategies

A branching strategy is the set of rules a team follows for creating, naming, and merging branches. The right strategy depends on your team size, release cadence, and deployment model.

Git Flow

Git Flow uses long-lived branches with a strict structure:

main ─────────────────────── (production releases)
  \                       /
   develop ──────────────── (integration branch)
     \         \        /
      feature-a  feature-b

Branches in Git Flow

• main — always reflects production. Only receives merges from release or hotfix branches.
• develop — integration branch. Features merge here first.
• feature/ — one per feature, branched from develop, merged back into develop.
• release/ — branched from develop when preparing a release. Bug fixes go here, then it merges into both main and develop.
• hotfix/ — branched from main for urgent production fixes. Merges into both main and develop.

Pros

• Clear separation between development and production
• Well-suited for scheduled releases (e.g., every 2 weeks)
• Multiple versions can be maintained simultaneously

Cons

• Complex — many branch types and merge rules
• Long-lived branches often lead to painful merge conflicts
• Slow for teams that deploy continuously

GitHub Flow

GitHub Flow is much simpler — there is only one long-lived branch: main.

main ──A──B──────E──F──────── (always deployable)
          \     /   \     /
           C──D      G──H
           (PR)       (PR)

Rules

1. main is always deployable
2. Create a branch from main for every change
3. Open a pull request when ready for review
4. After review, merge into main
5. Deploy from main

Pros

• Simple — only one rule to follow
• Fast feedback loop with pull requests
• Works well with continuous deployment

Cons

• No separation between "development" and "production"
• Harder to maintain multiple release versions
• Requires good CI/CD to catch issues before merging

Trunk-Based Development

Trunk-based development takes simplicity further — everyone commits to main (the "trunk") directly or via very short-lived branches (hours, not days).

main ──A──B──C──D──E──F──G──── (everyone commits here)
          \  /      \  /
           ──        ──
        (short)   (short)

Rules

1. Everyone works on main (or merges within hours)
2. Branches live for a day at most
3. Use feature flags to hide incomplete work
4. CI runs on every commit

Pros

• Minimal merge conflicts (branches are short-lived)
• Fastest integration cycle
• Encourages small, incremental changes

Cons

• Requires mature CI/CD and testing
• Feature flags add complexity to the codebase
• Not suitable if you cannot deploy frequently

Comparison

Which Should You Choose?

• Just starting out? Use GitHub Flow. It is simple and effective.
• Shipping versioned software (mobile apps, libraries)? Git Flow gives you the structure.
• Deploying multiple times a day? Trunk-based development minimizes friction.

There is no universally correct answer. The best strategy is the one your team can follow consistently.

Key Insight

Branching strategies are about people and process, not Git features. Git supports all of these approaches equally well. Pick the one that matches how your team actually ships code.