Stratégies Git : Gitflow vs GitHub Flow

Your Git branching strategy directly impacts how fast your team ships code, how often deployments break, and how painful merge conflicts become. The three dominant strategies in 2026 are Gitflow, GitHub Flow, and Trunk-Based Development. Each makes different trade-offs between release control, development speed, and operational complexity. This guide explains each strategy in depth, with practical examples and a decision framework to help you choose.

Gitflow: Structured Release Management

Gitflow, introduced by Vincent Driessen in 2010, uses multiple long-lived branches to manage releases. It is the most structured of the three strategies, with dedicated branches for features, releases, and hotfixes. Gitflow is designed for projects with scheduled releases, where each release goes through a formal testing and stabilization phase.

The model uses five branch types: main (production code), develop (integration branch), feature branches (new work), release branches (release stabilization), and hotfix branches (urgent production fixes). Code flows from feature branches into develop, from develop into release branches, and finally into main.

Gitflow Branch Structure

# Gitflow in practice

# 1. Start a new feature
git checkout develop
git pull origin develop
git checkout -b feature/user-authentication

# Work on the feature...
git add .
git commit -m "feat: add JWT authentication middleware"
git commit -m "feat: add login/logout endpoints"
git commit -m "test: add auth integration tests"

# 2. Finish feature — merge back to develop
git checkout develop
git pull origin develop
git merge --no-ff feature/user-authentication
git push origin develop
git branch -d feature/user-authentication

# 3. Create a release branch when ready
git checkout develop
git checkout -b release/2.1.0

# Stabilize: only bug fixes allowed on release branch
git commit -m "fix: correct session timeout handling"
git commit -m "docs: update API documentation for v2.1"

# 4. Finish release — merge to main AND develop
git checkout main
git merge --no-ff release/2.1.0
git tag -a v2.1.0 -m "Release 2.1.0"
git push origin main --tags

git checkout develop
git merge --no-ff release/2.1.0
git push origin develop
git branch -d release/2.1.0

# 5. Hotfix for production issue
git checkout main
git checkout -b hotfix/2.1.1

git commit -m "fix: patch critical XSS vulnerability"

git checkout main
git merge --no-ff hotfix/2.1.1
git tag -a v2.1.1 -m "Hotfix 2.1.1"
git push origin main --tags

git checkout develop
git merge --no-ff hotfix/2.1.1
git push origin develop
git branch -d hotfix/2.1.1

GitHub Flow: Simple and Continuous

GitHub Flow is a lightweight branching strategy built around a single principle: anything in the main branch is deployable. Developers create short-lived feature branches from main, open pull requests for code review, and merge directly back to main. The main branch is always in a deployable state.

GitHub Flow is designed for continuous delivery. Every merged pull request can be (and often is) deployed immediately. There are no release branches, no develop branch, and no hotfix branches. The simplicity of this model makes it extremely popular among teams practicing continuous deployment.

# GitHub Flow in practice

# 1. Create a feature branch from main
git checkout main
git pull origin main
git checkout -b add-search-functionality

# 2. Make commits with clear messages
git add .
git commit -m "feat: add search index builder"
git commit -m "feat: implement fuzzy search with Fuse.js"
git commit -m "test: add search result ranking tests"
git commit -m "feat: add search UI with keyboard shortcuts"

# 3. Push and open a Pull Request
git push -u origin add-search-functionality
# Open PR on GitHub for code review

# 4. Address review feedback
git commit -m "refactor: extract search scoring logic"
git push

# 5. Merge to main (squash or merge commit)
# After CI passes and review is approved:
# Click "Squash and merge" on GitHub
# Or from command line:
git checkout main
git pull origin main
git merge --squash add-search-functionality
git commit -m "feat: add fuzzy search with keyboard shortcuts (#142)"
git push origin main
git branch -d add-search-functionality

# 6. Deploy main to production
# This typically happens automatically via CI/CD
# e.g., Vercel auto-deploys on push to main

Trunk-Based Development: Maximum Velocity

Trunk-Based Development (TBD) takes simplicity to the extreme: all developers commit directly to a single branch (trunk/main), or use very short-lived branches (lasting hours, not days). The trunk is always in a releasable state because every commit is small, tested, and self-contained.

TBD requires a fundamentally different mindset. Instead of building complete features on branches and merging them, developers break features into tiny, independently deployable increments. Unfinished features are hidden behind feature flags. The key discipline is: every commit to trunk must be safe to deploy.

# Trunk-Based Development in practice

# Option A: Direct commits to trunk
git checkout main
git pull origin main

# Make a small, self-contained change
git add .
git commit -m "feat: add search input component (hidden behind flag)"
git push origin main  # Triggers CI/CD

# Next small change
git commit -m "feat: add search API endpoint"
git push origin main

# Next increment
git commit -m "feat: wire search input to API"
git push origin main

# Enable the feature
git commit -m "feat: enable search feature flag for beta users"
git push origin main

# Option B: Short-lived branches (hours, not days)
git checkout main
git pull origin main
git checkout -b add-search-input  # Lives for 2-4 hours max

git add .
git commit -m "feat: add search input with debounced API call"

# Push and create a quick PR
git push -u origin add-search-input
# PR is reviewed quickly (< 1 hour), then merged

# Feature flags example
// featureFlags.ts
const flags = {
  SEARCH_ENABLED: process.env.SEARCH_ENABLED === 'true',
  NEW_CHECKOUT: process.env.NEW_CHECKOUT === 'true',
};

// Usage in component
function Header() {
  return (
    <nav>
      <Logo />
      {flags.SEARCH_ENABLED && <SearchBar />}
      <UserMenu />
    </nav>
  );
}

// Gradually roll out
// 1. Enable for internal team
// 2. Enable for 5% of users
// 3. Enable for 50% of users
// 4. Enable for 100% — remove flag

Strategy Comparison

Compare the three strategies across key dimensions to find the best fit for your team:

CI/CD Integration

Each strategy integrates differently with CI/CD pipelines. The complexity of your pipeline should match your branching strategy.

# GitHub Actions — CI/CD for GitHub Flow
name: CI/CD Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check
      - run: npm test -- --coverage
      - run: npm run build

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - name: Deploy to production
        run: npx vercel --prod --yes
        env:
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}

# Gitflow CI/CD would have additional workflows for:
# - develop branch (deploy to staging)
# - release/* branches (deploy to pre-production)
# - main branch (deploy to production)
# - hotfix/* branches (fast-track to production)

Branch Naming Conventions

Consistent branch naming improves traceability, enables CI/CD automation, and makes the git log readable:

Pull Request Best Practices

• Keep PRs small: aim for under 400 lines of changes. Large PRs get rubber-stamped, not reviewed. Break big features into a series of small, mergeable PRs.
• Write descriptive PR titles and descriptions. Include what changed, why it changed, and how to test it. Link to the relevant issue or ticket.
• Use PR templates to standardize the information reviewers need. Include sections for description, testing steps, screenshots (if UI changes), and a checklist.
• Require at least one approval before merging. For critical paths (auth, payments, data migrations), require two reviewers.
• Run all CI checks before allowing merge. Block PRs with failing tests, lint errors, or type errors from being merged.
• Prefer squash merges for feature branches to keep the main branch history clean and linear. Each squash commit represents one complete feature or fix.

Commit Message Conventions

Conventional Commits provide a structured format that enables automated changelogs, semantic versioning, and better git history:

# Conventional Commits format
# <type>(<scope>): <description>
#
# Types:
# feat:     New feature (minor version bump)
# fix:      Bug fix (patch version bump)
# docs:     Documentation only
# style:    Formatting, no code change
# refactor: Code change, no feature or fix
# perf:     Performance improvement
# test:     Adding/fixing tests
# chore:    Build process, dependencies
# ci:       CI/CD configuration

# Examples:
git commit -m "feat(auth): add OAuth 2.0 Google login"
git commit -m "fix(api): handle null response from payment gateway"
git commit -m "docs(readme): add deployment instructions"
git commit -m "refactor(db): migrate from raw SQL to Prisma ORM"
git commit -m "perf(images): add WebP conversion with lazy loading"
git commit -m "test(auth): add integration tests for JWT refresh"
git commit -m "chore(deps): upgrade Next.js to v16.1"

# Breaking changes (major version bump):
git commit -m "feat(api)!: change authentication from API key to OAuth"
# Or with body:
git commit -m "feat(api): migrate to v2 endpoint format

BREAKING CHANGE: All API endpoints now require /v2/ prefix.
Old endpoints will return 301 redirects for 90 days."

Decision Framework

Use this framework to choose the right strategy based on your team and project characteristics:

FAQ