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 fixes

Workflow 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.1

Pros 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 work

Workflow 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-profile

Key Principles

  • Main is always deployable: Never commit broken code to main
  • Descriptive branch names: Use clear names like add-user-auth or fix-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 releases

Workflow 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 main

Key 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       | Single

Best 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 rebasing

3. 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 errors

4. 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:check

Choosing 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: