Theme
Lecon 8 / 8NouvelleMAJ 27 nov. 2025
Parcours Cours Git pour débutants

Workflows Git (intro simple)

Un workflow Git est une méthode organisée pour gérer les branches et la collaboration au sein d'une équipe.

#git#workflow#trunkbased#gitflow#featurebranch#cicd

Progression

8 / 8

Derniere mise a jour

27 nov. 2025

Etat

Nouveau

Qu'est-ce qu'un workflow Git ?

Un workflow Git est une méthode organisée pour gérer les branches et la collaboration au sein d'une équipe.

Il définit :

  • Comment et quand créer des branches
  • Comment nommer les branches
  • Quand et comment fusionner
  • Qui a le droit de fusionner dans main

Feature Branch Workflow

Le workflow le plus simple et le plus courant pour les petites équipes.

Principe

Une branche = une fonctionnalité/correction

main:      A --- B --------- F --------- I
                 \         /           /
feature-1:        C ----- D           /
                           \         /
feature-2:                  G ----- H

Étapes

  1. Toujours partir de main à jour :
git switch main
git pull origin main
  1. Créer une branche pour la fonctionnalité :
git switch -c feature/login-system
  1. Développer et committer régulièrement :
git add .
git commit -m "feat: add login form"
# ... plus de travail ...
git commit -m "feat: add password validation"
  1. Pusher la branche :
git push -u origin feature/login-system

  1. Créer une Pull Request :

    • Revue de code par l'équipe
    • Tests automatisés (CI)
    • Approbation

  2. Merger dans main :

    • Via l'interface GitHub/GitLab
    • Ou en ligne de commande :
git switch main
git merge feature/login-system
git push origin main
  1. Supprimer la branche :
git branch -d feature/login-system
git push origin --delete feature/login-system

Avantages

  • Simple à comprendre et mettre en place
  • Isolation des fonctionnalités
  • Revue de code via PRs
  • Flexibilité : plusieurs features en parallèle

Inconvénients

  • Peut devenir chaotique avec de grandes équipes
  • Pas de gestion explicite des releases

Trunk-Based Development (moderne 2025)

Le workflow recommandé en 2025 pour les équipes pratiquant le CI/CD et les déploiements fréquents.

Principe

Tous les développeurs commettent sur main (le "trunk") très fréquemment.

main:  A - B - C - D - E - F - G - H - I
       ↑   ↑   ↑   ↑   ↑   ↑   ↑   ↑   ↑
      Dev1 Dev2 Dev1 Dev3 Dev1 Dev2 Dev1 Dev3 Dev2

Règles

Branches très courtes : maximum 1-2 jours, souvent quelques heures.

Commits fréquents : plusieurs fois par jour sur main (ou via PRs ultra-courtes).

Feature flags : pour cacher les fonctionnalités non finies en production.

Tests automatisés robustes : car on déploie main directement.

Déploiement continu : main est toujours déployable.

Étapes

  1. Créer une branche courte :
git switch -c small-fix
  1. Faire un petit changement (1-2 heures max) :
git add .
git commit -m "fix: update button color"
  1. Pusher et merger rapidement :
git push -u origin small-fix
# Créer PR → Review express → Merge
  1. Supprimer immédiatement la branche :
git branch -d small-fix

Utilisation des Feature Flags

Pour développer une grosse fonctionnalité sans attendre :

// Code avec feature flag
if (featureFlags.newCheckout) {
  // Nouveau système de checkout (en développement)
  return <NewCheckout />
} else {
  // Ancien système (stable)
  return <OldCheckout />
}

On active le flag quand la feature est prête.

Avantages

  • Intégration continue réelle
  • Moins de conflits (branches courtes)
  • Déploiement rapide des fixes
  • Historique linéaire et propre
  • Utilisé par Google, Facebook, etc.

Inconvénients

  • Nécessite une discipline d'équipe
  • Nécessite des tests automatisés solides
  • Courbe d'apprentissage pour les débutants

GitFlow (workflow traditionnel)

Workflow plus complexe, historiquement populaire mais moins utilisé en 2025.

Principe

Branches multiples avec rôles spécifiques :

main:      A ----------- E ----------- J
            \           /           /
develop:     B - C - D ----------- I
              \       /           /
feature:       F --- G           /
                      \         /
release:               H ------

Branches principales :

  • main : code en production
  • develop : intégration des features

Branches temporaires :

  • feature/* : nouvelles fonctionnalités
  • release/* : préparation des releases
  • hotfix/* : corrections urgentes en production

Workflow complet

  1. Feature : partir de develop
git switch develop
git pull
git switch -c feature/nouvelle-fonctionnalite
# ... développement ...
git push origin feature/nouvelle-fonctionnalite
# PR vers develop
  1. Release : partir de develop quand prêt
git switch -c release/1.2.0
# ... tests, corrections de bugs ...
git switch main
git merge release/1.2.0
git tag v1.2.0
git push --tags
  1. Hotfix : partir de main en urgence
git switch main
git switch -c hotfix/bug-critique
# ... correction ...
git switch main
git merge hotfix/bug-critique
git switch develop
git merge hotfix/bug-critique

Avantages

  • Structure claire pour releases planifiées
  • Main toujours stable
  • Bon pour logiciels avec versions (desktop, mobile)

Inconvénients

  • Complexe pour débutants
  • Lent : beaucoup de branches à gérer
  • Moins adapté au web et déploiement continu
  • En déclin en 2025 au profit de Trunk-Based

Conventions de commits

Conventional Commits (standard 2025)

Format standardisé pour les messages de commit, très utilisé en 2025.

Format :

<type>(<scope>): <description>

[body optionnel]

[footer optionnel]

Types :

  • feat: nouvelle fonctionnalité
  • fix: correction de bug
  • docs: documentation
  • style: formatage (pas de changement de code)
  • refactor: refactoring
  • perf: amélioration de performance
  • test: ajout/modification de tests
  • build: système de build (webpack, npm, etc.)
  • ci: CI/CD (GitHub Actions, GitLab CI, etc.)
  • chore: maintenance (dépendances, config, etc.)
  • revert: annulation d'un commit précédent

Exemples :

git commit -m "feat(auth): add OAuth2 login"
git commit -m "fix(api): handle null responses correctly"
git commit -m "docs(readme): update installation instructions"
git commit -m "refactor(database): simplify query logic"
git commit -m "perf(images): lazy load product images"
git commit -m "chore(deps): update dependencies"

Avec breaking change :

git commit -m "feat(api)!: change endpoint structure
 
BREAKING CHANGE: API endpoints now use /api/v2/ prefix"

Avantages des Conventional Commits

  • Historique lisible et standardisé
  • Génération automatique de CHANGELOG
  • Versioning sémantique automatique (SemVer)
  • Filtrage facile des commits par type

Bonnes pratiques universelles

Pour tous les workflows

Commits atomiques : un commit = un changement logique complet.

Messages clairs : expliquer le "pourquoi", pas le "quoi".

Branches à jour : rebase ou merge régulièrement depuis main.

Tests avant merge : CI/CD pour valider automatiquement.

Revue de code : au moins une personne revoit chaque PR.

Main protégée : pas de push direct, uniquement via PRs.

Suppression des branches : nettoyer après merge.

Taille des PRs

Petites PRs (recommandé) :

  • Moins de 400 lignes modifiées
  • Review plus rapide et efficace
  • Moins de risque de bugs
  • Moins de conflits

Indicateurs :

  • ✅ < 200 lignes : excellent
  • ⚠️ 200-400 lignes : acceptable
  • ❌ > 400 lignes : à découper

Résolution de conflits avancée

Stratégies de merge

Recursive (par défaut) :

git merge feature

Ours : en cas de conflit, garder notre version :

git merge -X ours feature

Theirs : en cas de conflit, garder leur version :

git merge -X theirs feature

Rebase interactif

Nettoyer l'historique avant de merger :

git rebase -i main

Commandes disponibles :

  • pick : garder le commit
  • reword : modifier le message
  • edit : modifier le commit
  • squash : fusionner avec le commit précédent
  • drop : supprimer le commit

Exemple :

pick a3f5b21 feat: add login
squash b8c4d92 fix: typo in login
reword c1e2f53 feat: add logout
drop d4f6g78 debug: console.log

Intégration CI/CD

GitHub Actions exemple

.github/workflows/main.yml :

name: CI/CD Pipeline
 
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test
      - name: Run linter
        run: npm run lint
 
  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: echo "Deploying..."

GitLab CI exemple

.gitlab-ci.yml :

stages:
  - test
  - deploy
 
test:
  stage: test
  script:
    - npm install
    - npm test
    - npm run lint
 
deploy:
  stage: deploy
  script:
    - echo "Deploying to production"
  only:
    - main

Quel workflow choisir ?

Pour débuter (1-3 développeurs)

Feature Branch Workflow

  • Simple à comprendre
  • PRs pour la revue de code
  • Suffisant pour petits projets

Pour équipe agile avec CI/CD (recommandé 2025)

Trunk-Based Development

  • Branches très courtes
  • Intégration continue
  • Déploiements fréquents
  • Feature flags pour grosses features

Pour releases planifiées (logiciels desktop/mobile)

GitFlow (ou variante simplifiée)

  • Branches release pour stabilisation
  • Hotfix pour production
  • Main = production stable

Résumé comparatif

WorkflowComplexitéVitesse de livraisonAdapté pour
Feature Branch🟢 Simple🟡 MoyennePetites équipes, débutants
Trunk-Based🟡 Moyenne🟢 RapideÉquipes agiles, web, CI/CD
GitFlow🔴 Complexe🔴 LenteReleases planifiées, desktop

Liens vers la partie suivante

  • Félicitations ! Vous avez terminé le cours Git. Retour à README

Tags

#git #workflow #trunkbased #gitflow #featurebranch #cicd #conventionalcommits