Git Branching Strategies: GitFlow, Trunk-Based & GitHub Flow

A Git branching strategy defines the rules for creating, naming, merging, and deleting branches in a repository. The right strategy depends on team size, release cadence, and deployment model. Studies show that teams using trunk-based development deploy 2× more frequently and have 3× lower change failure rates compared to long-lived branch strategies, according to the DORA State of DevOps reports. This guide covers the four most widely adopted branching models with concrete workflows, commands, and a comparison to help you choose.

What Is GitFlow?

GitFlow, introduced by Vincent Driessen in 2010, uses two permanent branches — main (production) and develop (integration) — plus three types of supporting branches: feature/*, release/*, and hotfix/*. It is best suited for projects with scheduled releases and long support cycles.

# Start a feature
git checkout develop
git checkout -b feature/user-auth

# Work on the feature, then merge back
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

# Create a release
git checkout develop
git checkout -b release/1.2.0
# bump version, fix last-minute bugs
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git checkout develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

# Hotfix from production
git checkout main
git checkout -b hotfix/fix-login
# apply fix
git checkout main
git merge --no-ff hotfix/fix-login
git tag -a v1.2.1 -m "Hotfix 1.2.1"
git checkout develop
git merge --no-ff hotfix/fix-login
git branch -d hotfix/fix-login

What Is Trunk-Based Development?

In trunk-based development (TBD), all developers commit directly to a single branch — main (the "trunk"). Feature branches, if used at all, live for less than 24 hours. This strategy requires strong CI, feature flags, and high test coverage. Google, Meta, and Microsoft all use variants of TBD at scale.

# Short-lived branch (optional)
git checkout main
git checkout -b feat/add-avatar
# small, focused change — typically < 1 day of work
git commit -m "feat: add avatar component"
git push origin feat/add-avatar
# open PR, get review, squash merge into main
# CI/CD deploys main automatically

# Or commit directly to main (for smaller teams)
git checkout main
git pull --rebase
git commit -m "fix: correct date formatting"
git push origin main

Feature flags decouple deployment from release. You merge incomplete features behind a flag, deploy the code, and toggle the flag when the feature is ready. Tools like LaunchDarkly, Unleash, or simple environment variables serve this purpose.

What Is GitHub Flow?

GitHub Flow is a simplified model: main is always deployable, everything else happens in feature branches with pull requests. There is no develop branch or release branches. It is the default strategy for most SaaS teams and open-source projects.

# 1. Create a branch from main
git checkout -b feature/search-api

# 2. Commit changes
git add .
git commit -m "feat: add search endpoint"

# 3. Push and open a pull request
git push -u origin feature/search-api
gh pr create --title "feat: add search endpoint" --body "Adds /api/search"

# 4. Review, discuss, and iterate on the PR

# 5. Merge to main (usually squash merge)
gh pr merge --squash

# 6. Deploy main (automated via CI/CD)

How Do Release Branches Work?

Release branches are long-lived branches cut from main at a specific point in time. They are used when you need to maintain multiple versions simultaneously (e.g., release/3.x and release/4.x). Bug fixes are cherry-picked from main into the relevant release branches.

# Cut a release branch
git checkout main
git checkout -b release/4.x
git push -u origin release/4.x

# Later — cherry-pick a fix from main into release/4.x
git checkout release/4.x
git cherry-pick abc123
git push origin release/4.x

# Tag a patch release
git tag -a v4.0.1 -m "Patch 4.0.1"
git push origin v4.0.1

How Do These Strategies Compare?

Key Takeaways

• • Use GitFlow when you have scheduled releases and need formal release gates
• • Use trunk-based development when you want maximum velocity and have strong CI/CD and feature flags
• • Use GitHub Flow as a pragmatic default for SaaS teams that deploy continuously
• • Use release branches when you support multiple product versions in parallel
• • Regardless of strategy, keep branches short-lived — the DORA research consistently shows shorter branch lifetimes correlate with higher engineering performance
• • Protect main with required status checks and code review regardless of which model you adopt