Git Branching Strategies

Branching Strategies at a Glance

Each strategy balances complexity against deployment speed differently. The diagram below shows how branches flow in each model.

Git Flow

Git Flow is a structured branching model designed by Vincent Driessen. It uses five types of branches, each with a clear purpose:

# Start a new feature
git switch develop
git switch -c feature/user-auth

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

# Create a release branch
git switch develop
git switch -c release/2.0.0
# ... fix bugs, bump version ...
git switch main
git merge --no-ff release/2.0.0
git tag -a v2.0.0 -m "Release 2.0.0"
git switch develop
git merge --no-ff release/2.0.0
git branch -d release/2.0.0

# Emergency hotfix from production
git switch main
git switch -c hotfix/fix-login-crash
# ... fix the bug ...
git switch main
git merge --no-ff hotfix/fix-login-crash
git tag -a v2.0.1 -m "Hotfix 2.0.1"
git switch develop
git merge --no-ff hotfix/fix-login-crash
git branch -d hotfix/fix-login-crash

GitHub Flow

GitHub Flow is a lightweight model with one rule: main is always deployable. Everything else happens in short-lived feature branches.

1. Create a branch from main
2. Make commits with descriptive messages
3. Open a pull request for code review
4. Discuss, review, and iterate
5. Merge to main
6. Deploy immediately

# Create a feature branch from main
git switch main
git pull origin main
git switch -c feature/add-search

# Make changes and push
git add src/search.js
git commit -m "Add search bar component"
git push -u origin feature/add-search

# After PR review and approval, merge on GitHub
# Then clean up locally
git switch main
git pull origin main
git branch -d feature/add-search

Trunk-Based Development

In trunk-based development, everyone commits directly to main (the trunk) or uses extremely short-lived feature branches that last less than a day. The trunk is always in a releasable state.

Key Practices

• Short-lived branches — merge within hours, never more than 1-2 days
• Feature flags — hide incomplete features behind toggles so they don't affect production
• Continuous integration — automated tests run on every commit to catch breakage immediately
• Small, frequent commits — reduce merge conflict risk by integrating constantly

# Option A: Commit directly to main (small teams)
git switch main
git pull origin main
# Make a small, self-contained change
git add src/button.css
git commit -m "Increase button padding for accessibility"
git push origin main

# Option B: Short-lived branch (larger teams)
git switch main
git pull origin main
git switch -c feat/improve-button
# Make change, push, open PR
git add src/button.css
git commit -m "Increase button padding for accessibility"
git push -u origin feat/improve-button
# PR reviewed and merged same day — branch deleted

GitLab Flow

GitLab Flow is a middle ground between Git Flow's complexity and GitHub Flow's simplicity. It adds environment branches that represent deployment stages.

Environment Branches

# Develop on a feature branch
git switch main
git switch -c feature/dark-mode

# After review, merge to main
git switch main
git merge --no-ff feature/dark-mode
git branch -d feature/dark-mode

# Promote to staging for QA
git switch staging
git merge main
git push origin staging
# Staging CI/CD deploys to staging environment

# After QA approval, promote to production
git switch production
git merge staging
git push origin production
# Production CI/CD deploys to live

Comparison Table

Side-by-side comparison of all four branching strategies:

How to Choose

Use this decision guide based on your team's situation:

Choose Git Flow if:

• You have scheduled releases with version numbers (v1.0, v2.0)
• Multiple versions are maintained in production simultaneously
• Your team is large enough to benefit from formal release management
• You build mobile apps, desktop software, or published libraries

Choose GitHub Flow if:

• You deploy continuously (multiple times per day or week)
• You want simplicity — one main branch, feature branches, PRs
• Your team is small to medium and everyone reviews PRs
• You're building a web application or API

Choose Trunk-Based Development if:

• You have a robust CI/CD pipeline with fast, reliable tests
• Your team practices feature flags and small, incremental changes
• You want maximum deployment velocity
• Your engineers are experienced and disciplined about keeping main green

Choose GitLab Flow if:

• You need a staging environment for QA before production
• You want more control than GitHub Flow but less overhead than Git Flow
• Your deployment requires promotion through environments (dev → staging → production)
• Compliance or regulation requires a staging gate

Interview Questions