Branching Strategies: Git Flow and Trunk-Based Development

What Is a Branching Strategy?

When a team uses Git, every developer works with a shared history of commits. Without agreed-upon rules for how to create, name, and merge branches, that history quickly becomes impossible to read or trust. A branching strategy is a set of conventions that defines which branches exist, what each one is for, and how code moves from one branch to another.

Two strategies dominate professional practice today: Git Flow, introduced by Vincent Driessen in 2010, and Trunk-Based Development (TBD), favored by teams practicing continuous integration and continuous delivery (CI/CD). Neither is universally superior; the right choice depends on team size, release cadence, and product maturity.

---

Git Flow

Git Flow defines a small set of long-lived branches and supporting short-lived branches with strict rules about what may merge into what.

Long-Lived Branches

• main (sometimes called `master`) — always reflects production-ready, released code. Direct commits are never made here.
• develop — the integration branch. Completed features land here and accumulate until a release is prepared.

Short-Lived Supporting Branches

• feature/ branches — created from `develop`, merged back into `develop` when work is finished. Naming convention: `feature/<short-description>`, e.g., `feature/user-login`.
• release/ branches — branched from `develop` when the team is ready to stabilize a version. Only bug fixes are added here; no new features. When ready, the release branch merges into both `main` (tagging the version) and back into `develop` to capture any last-minute fixes. Naming: `release/1.4.0`.
• hotfix/ branches — the only branches created directly from `main`. Used to patch a critical production bug. When complete, a hotfix merges into both `main` and `develop`. Naming: `hotfix/1.4.1`.

Merge Rules Summary

| Branch type | Created from | Merges into |

|---|---|---|

| feature/* | develop | develop |

| release/* | develop | main AND develop |

| hotfix/* | main | main AND develop |

When Git Flow Fits

Git Flow suits projects with scheduled, versioned releases — for example, a packaged software product shipped quarterly, a large e-commerce platform with a formal QA cycle, or any team that must maintain multiple versions in production simultaneously. The release branch gives the team a staging area to harden a version without blocking new feature work on `develop`.

Caution

Git Flow adds overhead. Long-running branches accumulate divergence, making merges harder and increasing merge conflict risk. Driessen himself added a note to his original post acknowledging that teams doing continuous delivery may find Git Flow unnecessarily complex.

---

Trunk-Based Development

In Trunk-Based Development, all developers integrate their work into a single shared branch — the trunk, usually called `main` — as frequently as possible, ideally at least once per day.

Core Rules

• There is one permanent branch: main (trunk). All work targets it.
• Feature branches, when used at all, are very short-lived — typically no more than one or two days before merging.
• Teams use feature flags (also called feature toggles) to hide incomplete functionality from end users while still integrating code into main.
• Releases are cut from main, often by tagging a commit or using a short-lived release branch that accepts only critical fixes.

When Trunk-Based Development Fits

TBD excels when a team deploys frequently — sometimes many times per day. Small startups doing continuous deployment, teams with mature automated test suites, and experienced developers who commit small, focused changes benefit most. It reduces the pain of integration by making integration continuous rather than a big-bang event.

Trade-offs

TBD demands discipline and tooling: thorough automated tests must run before every merge so broken code never stays in main for long. It is harder to adopt on teams with junior contributors or on products where releases must be certified well in advance.

---

Comparing the Two Strategies

| Dimension | Git Flow | Trunk-Based Development |

|---|---|---|

| Permanent branches | main, develop | main only |

| Feature branch lifetime | Days to weeks | Hours to 1–2 days |

| Release process | Dedicated release branch | Tag on main; feature flags |

| Hotfix approach | hotfix/* branch from main | Direct fix to main, fast deploy |

| Best for | Scheduled, versioned releases | Continuous delivery, frequent deploys |

| Merge conflict risk | Higher (long-lived branches) | Lower (frequent integration) |

---

Choosing the Right Strategy

Ask these questions when evaluating a project:

1. How often do you release? Daily or more → lean toward TBD. Monthly or quarterly → Git Flow is a stronger fit.

2. How many versions must you support simultaneously? More than one active release → Git Flow's release branches help isolate maintenance.

3. What is your test automation coverage? Low coverage makes TBD risky; the fast merge pace can push untested code to main.

4. How large and distributed is the team? Larger teams benefit from the explicit structure of Git Flow; small, co-located teams often move faster with TBD.

---

A Note on Safety and Good Practice

Version control itself is a form of technical safety. Protecting the `main` branch with branch protection rules — requiring pull request reviews and passing automated tests before any merge — prevents accidental deletion of production history and ensures a working codebase is always available. Treat `main` as a protected asset, just as you would protect critical infrastructure in any trade.