Git Workflow Strategies: GitFlow, GitHub Flow, and Trunk-Based Development
Compare popular Git workflow strategies including GitFlow, GitHub Flow, and Trunk-Based Development. Learn best practices for branching, merging, and team collaboration.
Why Git Workflows Matter
A well-defined Git workflow helps teams collaborate efficiently, manage releases systematically, and maintain code quality. The right workflow depends on your team size, release cadence, and deployment strategy.
GitFlow: The Classic Workflow
Overview
GitFlow, created by Vincent Driessen in 2010, uses multiple long-lived branches and is designed for projects with scheduled releases. It's comprehensive but can be complex.
Branch Structure
Main Branches: ├── main (or master) - Production-ready code └── develop - Integration branch for features Supporting Branches: ├── feature/* - New features ├── release/* - Release preparation └── hotfix/* - Emergency production fixesWorkflow Example
# Start a new feature
git checkout develop
git checkout -b feature/user-authentication
# Work on feature
git add .
git commit -m "Add login form"
git commit -m "Implement JWT authentication"
# Finish feature
git checkout develop
git merge --no-ff feature/user-authentication
git branch -d feature/user-authentication
git push origin develop
# Prepare release
git checkout -b release/1.0.0 develop
# Bug fixes only on release branch
git commit -m "Update version to 1.0.0"
# Finish release
git checkout main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "Release version 1.0.0"
git checkout develop
git merge --no-ff release/1.0.0
git branch -d release/1.0.0
# Emergency hotfix
git checkout -b hotfix/1.0.1 main
git commit -m "Fix critical security bug"
git checkout main
git merge --no-ff hotfix/1.0.1
git tag -a v1.0.1
git checkout develop
git merge --no-ff hotfix/1.0.1
git branch -d hotfix/1.0.1Pros and Cons
Advantages:
- Clear separation between production and development
- Supports multiple versions in production
- Well-documented and widely understood
- Good for scheduled releases
Disadvantages:
- Complex with many branch types
- Can create merge conflicts
- Overkill for continuous deployment
- Long-lived branches can diverge significantly
Best for: Traditional release cycles, versioned software, large teams
GitHub Flow: Simplified Workflow
Overview
GitHub Flow is a lightweight, branch-based workflow designed for teams that deploy frequently. It has only one long-lived branch (main) and emphasizes continuous deployment.
Branch Structure
├── main - Always deployable └── feature branches - Short-lived branches for any workWorkflow Example
# Create feature branch
git checkout main
git pull origin main
git checkout -b add-user-profile
# Work and commit
git add .
git commit -m "Add user profile component"
git push origin add-user-profile
# Open Pull Request on GitHub
# Code review happens here
# CI/CD runs automated tests
# After approval, merge to main
git checkout main
git pull origin main
# Usually done via GitHub UI with "Squash and merge"
# Deploy main to production
# This happens automatically via CI/CD
# Delete feature branch
git branch -d add-user-profile
git push origin --delete add-user-profileKey Principles
- Main is always deployable: Never commit broken code to main
- Descriptive branch names: Use clear names like
add-user-authorfix-login-bug - Pull Requests for everything: All changes go through code review
- Deploy immediately after merge: Main branch deploys automatically
- Keep branches short-lived: Merge frequently to avoid conflicts
Pros and Cons
Advantages:
- Simple and easy to understand
- Fast feedback loop
- Minimal overhead
- Perfect for continuous deployment
- Encourages code review
Disadvantages:
- Requires mature CI/CD pipeline
- No separation between staging and production code
- Difficult to manage multiple versions
- Rollbacks can be challenging
Best for: SaaS applications, web apps with continuous deployment, small to medium teams
Trunk-Based Development
Overview
Trunk-Based Development (TBD) emphasizes working directly on the main branch (trunk) or using very short-lived feature branches. It's the workflow used by elite engineering teams practicing continuous integration.
Branch Structure
├── trunk (main) - Everyone commits here frequently └── release branches - Optional, created from trunk for releasesWorkflow Example
# Direct commits to trunk (for small changes)
git checkout main
git pull origin main
# Make small change
git add .
git commit -m "Update button color"
git push origin main
# Short-lived feature branch (< 1 day)
git checkout -b quick-feature
# Work for a few hours
git add .
git commit -m "Add feature"
git push origin quick-feature
# Create PR and merge immediately after CI passes
# Feature flags for incomplete features
git checkout main
// code.js
if (featureFlags.newFeature) {
// New code (not ready for production)
} else {
// Old code
}
git commit -m "Add new feature behind flag"
git push origin main // Safe to deploy!
# Release branches (optional)
git checkout -b release/2024-02-11 main
git push origin release/2024-02-11
# Deploy this branch to production
# Bug fixes cherry-picked back to mainKey Practices
- Commit frequently: Multiple times per day to main
- Small changes: Break work into small, incremental commits
- Feature flags: Hide incomplete features in production
- Strong CI/CD: Automated testing catches issues immediately
- Pair programming: Reduces need for code review delays
Pros and Cons
Advantages:
- Fastest integration and feedback
- Minimal merge conflicts
- Encourages small, incremental changes
- Highest code quality with proper CI/CD
- Used by Google, Facebook, etc.
Disadvantages:
- Requires excellent test coverage
- Needs robust feature flag system
- Cultural shift can be challenging
- Requires discipline and trust
Best for: High-performing teams, microservices, continuous deployment environments
Comparison Table
Aspect | GitFlow | GitHub Flow | Trunk-Based
----------------|--------------|--------------|-------------
Complexity | High | Low | Very Low
Branches | 5+ types | 2 types | 1-2 types
Release Cycle | Scheduled | Continuous | Continuous
CI/CD Required | Optional | Recommended | Essential
Team Size | Large | Any | Any
Learning Curve | Steep | Easy | Medium
Merge Frequency | Low | Medium | Very High
Conflict Risk | High | Medium | Low
Version Support | Multiple | Single | SingleBest Practices Across All Workflows
1. Write Good Commit Messages
# Good commit messages
git commit -m "Add user authentication with JWT"
git commit -m "Fix: Handle null pointer in user service"
git commit -m "Refactor: Extract payment logic to separate service"
# Use conventional commits
git commit -m "feat: add user profile page"
git commit -m "fix: resolve login redirect bug"
git commit -m "docs: update API documentation"
git commit -m "test: add unit tests for auth service"2. Keep Branches Up to Date
# Regularly sync with main
git checkout feature-branch
git fetch origin
git rebase origin/main # or merge
git push --force-with-lease # if rebasing3. Use Pull Request Templates
## Description
Brief description of changes
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests passed
- [ ] Manual testing completed
## Checklist
- [ ] Code follows style guidelines
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] No console errors4. Protect Your Main Branch
- Require pull request reviews
- Require status checks to pass
- Enforce linear history (squash or rebase)
- Require up-to-date branches before merging
- Restrict who can push to main
5. Automate Everything
# .github/workflows/ci.yml
name: CI
on:
pull_request:
branches: [main]
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run tests
run: npm test
- name: Run linter
run: npm run lint
- name: Check formatting
run: npm run format:checkChoosing the Right Workflow
Choose GitFlow if:
- You have scheduled, versioned releases
- You support multiple versions in production
- You have a large, distributed team
- Your deployment process is complex
Choose GitHub Flow if:
- You deploy frequently (daily/weekly)
- You have a single production environment
- You want simplicity over complexity
- Your team is comfortable with continuous deployment
Choose Trunk-Based Development if:
- You deploy multiple times per day
- You have excellent test coverage
- Your team embraces rapid iteration
- You use feature flags effectively
Migration Tips
If you're transitioning workflows:
- Start with a pilot team or project
- Document the new workflow clearly
- Provide training and support
- Adjust your CI/CD pipeline accordingly
- Be patient - cultural changes take time
Try Our Developer Tools
Improve your development workflow with our tools: