Git Branching Strategies

Git Branching Strategies

A branching strategy defines how your team uses branches to manage development, releases, and hotfixes. The right strategy depends on your release cadence and team size.

GitHub Flow (Recommended for Most Teams)

Simple, effective for continuous delivery:

main (always deployable)
 └── feature/user-auth    ← branch from main
 └── fix/login-bug        ← merge back to main via PR
 └── feature/dashboard

Workflow:

1. Branch from main
2. Write code, commit frequently
3. Open a pull request
4. Review and CI runs
5. Merge to main
6. Deploy from main

git switch main && git pull
git switch -c feature/user-auth
# ... commit changes ...
git push -u origin feature/user-auth
# Open PR on GitHub → Review → Merge

Good for: teams deploying continuously (multiple times per day), SaaS products, open-source projects.

Git Flow

More structured, suited for versioned releases:

main          ← released code only
develop       ← integration branch
├── feature/* ← branch from develop
├── release/* ← branch from develop when ready to release
└── hotfix/*  ← branch from main for urgent fixes

Branches:

• main — production-ready, tagged with versions
• develop — integration of completed features
• feature/name — new features, branch from develop
• release/1.2.0 — release preparation (bug fixes, docs), branch from develop, merge into main and develop
• hotfix/name — urgent production fixes, branch from main, merge into main and develop

# Start a feature
git switch develop && git pull
git switch -c feature/payment-gateway

# Finish feature
git switch develop
git merge --no-ff feature/payment-gateway
git branch -d feature/payment-gateway

# Start a release
git switch -c release/1.2.0 develop
# bump version, update changelog...
git switch main && git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Version 1.2.0"
git switch develop && git merge --no-ff release/1.2.0

Good for: apps with scheduled releases, multiple supported versions, mobile apps with app store submissions.

Trunk-Based Development

Everyone commits to main (trunk) at least once per day. Very short-lived branches (hours, not days):

main ← all developers commit here frequently

Feature work is hidden behind feature flags until ready. Requires a strong CI/CD pipeline and good test coverage.

Good for: large, experienced teams with mature CI/CD (Google, Facebook style).

Comparison

Strategy	Best for	Release cadence	Complexity
GitHub Flow	Most teams	Continuous	Low
Git Flow	Versioned releases	Scheduled	Medium
Trunk-Based	Large teams, mature CI	Continuous	High

Branch Naming Conventions

feature/user-authentication
feature/JIRA-123-payment-gateway
fix/login-redirect-bug
hotfix/critical-security-patch
chore/upgrade-dependencies
docs/api-reference
release/2.1.0

Consistent naming makes branches scannable and enables automation (e.g., auto-linking to issue trackers).

Pull Request Best Practices

1. Keep PRs small — 200–400 lines is ideal. Reviewers review larger PRs less carefully
2. One concern per PR — a refactor and a feature in one PR are hard to review
3. Write a good description — what changed and why, not just what
4. Link to the issue — Closes #123 auto-closes the issue on merge
5. Don’t rebase PRs under review — it makes review history harder to follow

Protecting Main

On GitHub, protect the main branch:

• Require pull request reviews before merging
• Require status checks to pass (CI)
• Prevent force pushes
• Require branches to be up to date before merging