Workflows Git — Git Flow, GitHub Flow, Trunk-Based
Module 04 45 min
Objectifs de la section
- Comprendre les 3 principaux workflows Git
- Choisir le workflow adapté à votre contexte
- Mettre en place GitHub Flow dans votre équipe
- Connaître les avantages et inconvénients de chaque approche
Les 3 principaux workflows
Vue d'ensemble comparative
| Critère | Git Flow | GitHub Flow | Trunk-Based |
|---|---|---|---|
| Complexité | Élevée | Simple | Très simple |
| Branches | Multiples (develop, release, hotfix) | Simple (feature + main) | Très peu |
| Déploiement | Périodique (releases) | Continu possible | Continu (CD) |
| Idéal pour | Logiciels versionnés | Apps web / SaaS | DevOps avancé |
| Taille équipe | Moyennes et grandes | Toutes tailles | Expérimentées |
Git Flow
Git Flow utilise plusieurs branches permanentes et des branches de support.
Structure des branches
Branches dans Git Flow
| Branche | Durée | Rôle |
|---|---|---|
main | Permanente | Code en production (toujours stable) |
develop | Permanente | Intégration des fonctionnalités |
feature/* | Temporaire | Développement de fonctionnalités |
release/* | Temporaire | Préparation d'une release |
hotfix/* | Temporaire | Corrections urgentes en production |
# Installer git-flow (outil CLI optionnel)
# macOS : brew install git-flow-avh
# Linux : apt-get install git-flow
# Initialiser git flow
git flow init
# Démarrer une fonctionnalité
git flow feature start nouvelle-fonctionnalite
# Équivalent à : git switch -c feature/nouvelle-fonctionnalite develop
# Terminer une fonctionnalité
git flow feature finish nouvelle-fonctionnalite
# Équivalent à : merge dans develop + suppression de la branche
# Démarrer une release
git flow release start v1.2.0
# Démarrer un hotfix
git flow hotfix start correction-critique
Quand choisir Git Flow ?
- Applications avec des cycles de release définis (mensuels, trimestriels)
- Logiciels avec plusieurs versions en production simultanément
- Équipes avec des processus de QA stricts
GitHub Flow
Un workflow simple et efficace, idéal pour le déploiement continu.
Les 6 étapes de GitHub Flow
# 1. Créer une branche depuis main (toujours à jour)
git switch main
git pull origin main
git switch -c feature/amelioration-recherche
# 2. Travailler et commiter
git add .
git commit -m "feat(search): ajouter la recherche par filtres avancés"
git push -u origin feature/amelioration-recherche
# 3. Ouvrir une PR
gh pr create --title "feat: recherche par filtres avancés" --base main
# 4. Revue de code, discussions, corrections
# 5. Tester en staging (optionnel, selon CI/CD)
# 6. Merger et supprimer la branche
gh pr merge --squash --delete-branch
Quand choisir GitHub Flow ?
- Applications web et SaaS (déploiement fréquent)
- Petites et moyennes équipes
- Projets open source
- Quand vous voulez quelque chose de simple à comprendre
Trunk-Based Development
Tout le monde commite directement sur la branche principale, avec des feature flags pour les fonctionnalités incomplètes.
# Commits directs sur main (très petits, très fréquents)
git switch main
git pull
# Petite fonctionnalité complète en quelques heures max
# avec feature flag si nécessaire
git add feature_x.py
git commit -m "feat: ajouter fonctionnalité X (désactivée par défaut)"
git push origin main
# Branche de courte durée acceptable (max 1-2 jours)
git switch -c feat/amelioration-rapide
# ... quelques commits ...
git switch main
git merge feat/amelioration-rapide
Quand choisir Trunk-Based ?
- Équipes très expérimentées avec forte culture DevOps
- Déploiement en continu (plusieurs fois par jour)
- Excellente couverture de tests (>80%)
- Maturité en feature flags