Team Branching Strategies

Introduction

A branching strategy is how your team uses main, feature branches, and releases day to day. There is no single correct answer—consistency matters more than the name. This chapter compares trunk-based development and Git Flow at a high level so you can follow your team's chosen model.

Prerequisites

Trunk-Based Development

Trunk = mainline branch (main).

Principles:

Short-lived feature branches (hours to few days)
Frequent merges to main
Small commits, CI green before merge
Feature flags hide incomplete work instead of long-lived branches

text

main:  A --- B --- C --- D --- E
         \     /       \     /
feature:  f1           f2

Best for:

Continuous delivery
Strong CI and code review culture
Web apps and services with fast release cycles

Tip

Default for Many Modern Teams

If your company does not document a strategy, assume small PRs to main until told otherwise.

Git Flow (Overview)

Classic model with multiple long-lived branches:

Branch	Role
`main`	Production-ready history
`develop`	Integration branch for next release
`feature/*`	New work off `develop`
`release/*`	Stabilize before production
`hotfix/*`	Emergency fix off `main`

text

main:     A ------------------- M release
                \             /
develop:   B --- C --- D --- E
                \       /
feature:         f1 --- f2

Best for:

Scheduled releases (e.g. mobile apps, enterprise on-prem)
Teams that explicitly document Git Flow

Cost:

More merge steps, more branches to track
Easy to drift from diagram if discipline slips

Learn the concepts—many startups simplify to trunk + tags only.

Compare at a Glance

	Trunk-based	Git Flow
Long-lived branches	Usually `main` only	`main` + `develop`
Feature branch lifetime	Short	Can be longer
Release process	Tag `main` often	`release/*` branch
Complexity	Lower	Higher
Hotfix	Branch off `main`, merge back	`hotfix/*` off `main`, merge to both

Protect main

Regardless of strategy:

Require Pull Request before merge
Require CI passing (tests, lint)
Block direct push or force push to main
Optional: require one approval

Configured in GitHub Settings → Branches → Branch protection—chapter 22 expands CI integration.

Pick One and Document

Team doc should answer:

Default branch name (main)
Feature branch naming (feature/, fix/)
Merge method (merge commit vs squash)
Who deletes branches after merge
Release tagging process (see Tags and Releases)

Changing strategy mid-project hurts—align in README or CONTRIBUTING.md.

FAQ

Git Flow vs GitHub Flow?

GitHub Flow ≈ trunk-based: branch off main, PR, merge, deploy—no develop.

One person project?

Use main + occasional feature branches—no need for Git Flow ceremony.

release branch when?

When you need QA freeze while develop continues—Git Flow pattern.

hotfix without Git Flow?

git switch -c hotfix/critical main → fix → PR to main → tag patch release.

develop branch stale?

Sign team process issue—trunk-based avoids second integration branch.

Monorepo branching?

Same rules—path owners and small PRs per service or package.