Search tools...
CMDK
← Blog
Development15 min

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:

Use String Diff Tool