Workflows Git avancés

Les workflows Git définissent comment les équipes organisent leur développement avec Git. Ce tutoriel explore les méthodologies les plus populaires et vous aide à choisir celle qui convient le mieux à votre équipe et votre projet.

Introduction aux workflows

Un workflow Git est un ensemble de règles et de conventions qui définissent :

• Comment créer et nommer les branches
• Quand et comment fusionner
• Qui peut faire quoi
• Comment gérer les releases

graph TD
    A[Choix du Workflow] --> B{Type de projet}
    B -->|Produit complexe| C[Git Flow]
    B -->|Web app agile| D[GitHub Flow]
    B -->|Déploiement continu| E[Trunk-Based]
    B -->|Équipe mixte| F[GitLab Flow]

Git Flow

Principe

Git Flow est un workflow structuré avec des branches spécialisées pour différents types de développement.

Structure des branches

gitgraph
    commit id: "Initial"
    branch develop
    checkout develop
    commit id: "Dev 1"
    branch feature/login
    checkout feature/login
    commit id: "Login 1"
    commit id: "Login 2"
    checkout develop
    merge feature/login
    commit id: "Dev 2"
    branch release/1.0
    checkout release/1.0
    commit id: "RC 1"
    checkout main
    merge release/1.0 tag: "v1.0"
    checkout develop
    merge release/1.0

Branches principales

main (ou master)

• Code de production
• Toujours stable
• Chaque commit = nouvelle version

develop

• Branche d’intégration
• Dernières fonctionnalités développées
• Base pour les nouvelles features

Branches de support

feature/

# Créer une feature branch
git checkout develop
git checkout -b feature/user-authentication

# Développer la fonctionnalité
# ... commits ...

# Merger dans develop
git checkout develop
git merge --no-ff feature/user-authentication
git branch -d feature/user-authentication

release/

# Créer une release branch
git checkout develop
git checkout -b release/1.2.0

# Finaliser la release (bug fixes, version bump)
echo "1.2.0" > VERSION
git commit -am "Bump version to 1.2.0"

# Merger dans main et develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"

git checkout develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

hotfix/

# Créer un hotfix depuis main
git checkout main
git checkout -b hotfix/critical-security-fix

# Corriger le bug
# ... commits ...

# Merger dans main et develop
git checkout main
git merge --no-ff hotfix/critical-security-fix
git tag -a v1.2.1 -m "Hotfix version 1.2.1"

git checkout develop
git merge --no-ff hotfix/critical-security-fix
git branch -d hotfix/critical-security-fix

Outils Git Flow

# Installation de git-flow
# macOS
brew install git-flow

# Ubuntu
sudo apt-get install git-flow

# Initialisation
git flow init

# Commandes git-flow
git flow feature start user-auth
git flow feature finish user-auth

git flow release start 1.2.0
git flow release finish 1.2.0

git flow hotfix start critical-fix
git flow hotfix finish critical-fix

Avantages et inconvénients

✅ Avantages :

• Structure claire et prévisible
• Séparation nette des environnements
• Gestion robuste des releases
• Idéal pour les produits avec cycles de release

❌ Inconvénients :

• Complexité élevée
• Overhead pour les petites équipes
• Pas adapté au déploiement continu
• Branches de longue durée

GitHub Flow

Principe

Workflow simplifié centré sur la branche main avec des feature branches courtes.

gitgraph
    commit id: "Initial"
    commit id: "Feature A"
    branch feature/new-ui
    checkout feature/new-ui
    commit id: "UI 1"
    commit id: "UI 2"
    checkout main
    merge feature/new-ui
    commit id: "Deploy"
    branch feature/api-update
    checkout feature/api-update
    commit id: "API 1"
    checkout main
    merge feature/api-update
    commit id: "Deploy"

Workflow étape par étape

# 1. Créer une branche depuis main
git checkout main
git pull origin main
git checkout -b feature/improve-performance

# 2. Développer et commiter
# ... développement ...
git add .
git commit -m "feat: optimize database queries"

# 3. Pousser régulièrement
git push origin feature/improve-performance

# 4. Ouvrir une Pull Request
gh pr create --title "Improve database performance" \
             --body "Optimizes queries to reduce load time by 50%"

# 5. Review et discussion
# ... code review ...

# 6. Merger dans main
gh pr merge --squash

# 7. Déployer
# Déploiement automatique depuis main

Règles GitHub Flow

1. main est toujours déployable
2. Branches descriptives depuis main
3. Push fréquent vers origin
4. Pull Request pour toute modification
5. Review obligatoire avant merge
6. Merge et déploiement immédiat

Configuration GitHub

# .github/branch-protection.yml
protection_rules:
  main:
    required_status_checks:
      strict: true
      contexts:
        - continuous-integration
        - security-scan
    enforce_admins: true
    required_pull_request_reviews:
      required_approving_review_count: 2
      dismiss_stale_reviews: true
    restrictions:
      users: []
      teams: ["core-team"]

Avantages et inconvénients

✅ Avantages :

• Simplicité maximale
• Déploiement continu facile
• Feedback rapide
• Idéal pour les web apps

❌ Inconvénients :

• Pas de staging explicite
• Difficile pour les releases planifiées
• Nécessite une CI/CD robuste
• Peut être chaotique sans discipline

Trunk-Based Development

Principe

Développement directement sur la branche principale avec des branches de très courte durée (< 1 jour).

gitgraph
    commit id: "Initial"
    commit id: "Feature A"
    branch short-feature
    checkout short-feature
    commit id: "Quick fix"
    checkout main
    merge short-feature
    commit id: "Feature B"
    commit id: "Feature C"
    branch tiny-change
    checkout tiny-change
    commit id: "Typo fix"
    checkout main
    merge tiny-change
    commit id: "Feature D"

Pratiques clés

Commits fréquents

# Commits multiples par jour sur main
git add .
git commit -m "feat: add user validation (partial)"
git push origin main

# Quelques heures plus tard
git add .
git commit -m "feat: complete user validation"
git push origin main

Feature Flags

// Utiliser des feature flags pour le code non terminé
function processPayment(amount) {
    if (featureFlags.newPaymentSystem) {
        return newPaymentProcessor(amount);
    }
    return legacyPaymentProcessor(amount);
}

Branches très courtes

# Branche de maximum 1-2 jours
git checkout -b quick-fix/typo-correction
# ... correction rapide ...
git push origin quick-fix/typo-correction
# ... PR et merge immédiat ...

Release depuis trunk

# Release branches depuis main
git checkout main
git checkout -b release/2024.03.15
git tag v2024.03.15
git push origin release/2024.03.15
git push origin v2024.03.15

# Hotfixes directement sur main
git checkout main
# ... fix ...
git commit -m "hotfix: critical security patch"
git tag v2024.03.15.1
git push origin main
git push origin v2024.03.15.1

Avantages et inconvénients

✅ Avantages :

• Intégration continue maximale
• Pas de merge hell
• Feedback immédiat
• Simplicité extrême

❌ Inconvénients :

• Nécessite une discipline stricte
• Tests automatisés obligatoires
• Feature flags complexes
• Pas pour tous les types de projets

GitLab Flow

Principe

Combinaison de GitHub Flow avec des branches d’environnement.

gitgraph
    commit id: "Initial"
    branch feature/auth
    checkout feature/auth
    commit id: "Auth 1"
    commit id: "Auth 2"
    checkout main
    merge feature/auth
    branch staging
    checkout staging
    merge main
    commit id: "Staging deploy"
    branch production
    checkout production
    merge staging
    commit id: "Prod deploy"

Structure avec environnements

# Branches d'environnement
main          # Développement
staging       # Tests d'intégration
production    # Production

# Workflow
git checkout main
git checkout -b feature/new-api

# Développement
git push origin feature/new-api
# ... Pull Request vers main ...

# Déploiement staging
git checkout staging
git merge main
git push origin staging

# Tests en staging
# ... validation ...

# Déploiement production
git checkout production
git merge staging
git push origin production

Release branches

# Pour les releases planifiées
git checkout main
git checkout -b release/2.1.0

# Cherry-pick des features
git cherry-pick feature-commit-1
git cherry-pick feature-commit-2

# Déploiement de la release
git checkout production
git merge release/2.1.0
git tag v2.1.0

Forking Workflow

Principe

Chaque développeur a son propre fork du dépôt principal.

graph TD
    A[Dépôt Principal] --> B[Fork Développeur 1]
    A --> C[Fork Développeur 2]
    B --> D[Clone Local 1]
    C --> E[Clone Local 2]
    D --> F[Pull Request 1]
    E --> G[Pull Request 2]
    F --> A
    G --> A

Workflow complet

# 1. Fork du dépôt principal (via GitHub)

# 2. Clone de votre fork
git clone https://github.com/VOUS/projet.git
cd projet

# 3. Ajouter l'upstream
git remote add upstream https://github.com/ORIGINAL/projet.git

# 4. Créer une branche feature
git checkout -b feature/awesome-feature

# 5. Développer
# ... commits ...

# 6. Synchroniser avec upstream
git fetch upstream
git rebase upstream/main

# 7. Pousser vers votre fork
git push origin feature/awesome-feature

# 8. Créer une Pull Request vers l'upstream

Maintenance du fork

# Synchronisation régulière
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

# Nettoyage des branches
git branch -d feature/completed-feature
git push origin --delete feature/completed-feature

Choisir le bon workflow

Critères de décision

graph TD
    A[Choisir un Workflow] --> B{Taille équipe}
    B -->|1-3 devs| C[GitHub Flow]
    B -->|4-10 devs| D{Type projet}
    B -->|10+ devs| E[Git Flow ou Forking]
    
    D -->|Web app| F[GitHub Flow]
    D -->|Produit| G[Git Flow]
    D -->|Microservices| H[Trunk-Based]

Tableau comparatif

Mise en place d’un workflow

GitHub Flow - Configuration

# .github/workflows/ci.yml
name: CI/CD
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run tests
        run: npm test
      
  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: ./deploy.sh

Git Flow - Scripts

#!/bin/bash
# scripts/git-flow-feature.sh

FEATURE_NAME=$1

if [ -z "$FEATURE_NAME" ]; then
    echo "Usage: $0 <feature-name>"
    exit 1
fi

# Créer la feature branch
git checkout develop
git pull origin develop
git checkout -b "feature/$FEATURE_NAME"

echo "Feature branch feature/$FEATURE_NAME created"
echo "When done, run: git-flow-feature-finish.sh $FEATURE_NAME"

Trunk-Based - Hooks

#!/bin/bash
# .git/hooks/pre-push

# Vérifier que les tests passent avant push
npm test
if [ $? -ne 0 ]; then
    echo "Tests failed. Push aborted."
    exit 1
fi

# Vérifier que le code est formaté
npm run lint
if [ $? -ne 0 ]; then
    echo "Linting failed. Push aborted."
    exit 1
fi

Exercices pratiques

Exercice 1 : Simuler GitHub Flow

# 1. Créer un dépôt de test
mkdir github-flow-demo
cd github-flow-demo
git init
echo "# GitHub Flow Demo" > README.md
git add README.md
git commit -m "Initial commit"

# 2. Simuler le développement d'une feature
git checkout -b feature/add-calculator
echo "function add(a, b) { return a + b; }" > calculator.js
git add calculator.js
git commit -m "feat: add calculator function"

# 3. Simuler une Pull Request (merge)
git checkout main
git merge --no-ff feature/add-calculator
git branch -d feature/add-calculator

# 4. Répéter avec d'autres features
git checkout -b feature/add-tests
echo "// Tests for calculator" > calculator.test.js
git add calculator.test.js
git commit -m "test: add calculator tests"

git checkout main
git merge --no-ff feature/add-tests
git branch -d feature/add-tests

Exercice 2 : Expérimenter Git Flow

# 1. Initialiser Git Flow
git flow init

# 2. Créer une feature
git flow feature start user-authentication
echo "function login() { /* auth logic */ }" > auth.js
git add auth.js
git commit -m "feat: add login function"
git flow feature finish user-authentication

# 3. Créer une release
git flow release start 1.0.0
echo "1.0.0" > VERSION
git add VERSION
git commit -m "bump: version to 1.0.0"
git flow release finish 1.0.0

# 4. Simuler un hotfix
git flow hotfix start critical-fix
echo "// Fixed critical bug" >> auth.js
git add auth.js
git commit -m "fix: resolve critical authentication bug"
git flow hotfix finish critical-fix

Bonnes pratiques transversales

Messages de commit

# Convention Conventional Commits
feat: add new user authentication system
fix: resolve login timeout issue
docs: update API documentation
style: format code according to style guide
refactor: restructure user service
test: add unit tests for payment module
chore: update dependencies

Protection des branches

# Via GitHub CLI
gh api repos/:owner/:repo/branches/main/protection \
  --method PUT \
  --field required_status_checks='{"strict":true,"contexts":["ci"]}' \
  --field enforce_admins=true \
  --field required_pull_request_reviews='{"required_approving_review_count":2}'

Automatisation

# .github/workflows/workflow-enforcement.yml
name: Workflow Enforcement
on:
  pull_request:
    branches: [main]

jobs:
  check-branch-name:
    runs-on: ubuntu-latest
    steps:
      - name: Check branch name
        run: |
          if [[ ! "${{ github.head_ref }}" =~ ^(feature|fix|hotfix)/.+ ]]; then
            echo "Branch name must start with feature/, fix/, or hotfix/"
            exit 1
          fi

Ressources supplémentaires

Outils de workflow

• Git Flow AVH : Extension Git Flow améliorée
• GitHub CLI : Automatisation des workflows GitHub
• GitKraken Glo : Gestion de projet intégrée
• Sourcetree : Interface graphique avec support des workflows

Documentation

• Git Flow Original
• GitHub Flow Guide
• Trunk-Based Development
• GitLab Flow

Conclusion

Le choix du workflow Git dépend de nombreux facteurs : taille de l’équipe, type de projet, fréquence de déploiement, et culture d’entreprise. L’important est de choisir un workflow adapté à votre contexte et de s’y tenir de manière cohérente.

Dans le prochain tutoriel, nous explorerons les sous-modules Git et les sous-arbres pour gérer des projets complexes avec des dépendances externes.

Temps de lecture estimé : 35 minutes
Niveau : Avancé
Étape précédente : Résolution de conflits
Prochaine étape : Git sous-modules et sous-arbres