GitFlow et Trunk-Based Development
Pourquoi utiliser une stratégie de gestion de branches Git ?
Lorsque vous travaillez sur un projet, surtout en équipe, il est essentiel d'adopter une stratégie de gestion de branches Git cohérente. Ces stratégies vous aident à :
- Organiser le développement : Structurer le travail en parallèle de plusieurs développeurs
- Gérer les versions : Faciliter la maintenance de différentes versions du logiciel
- Assurer la qualité : Protéger votre code de production des erreurs et régressions
- Optimiser la collaboration : Clarifier le processus pour tous les membres de l'équipe
GitFlow
GitFlow est un modèle de workflow Git formalisé par Vincent Driessen en 2010. Il définit un ensemble structuré de branches et de règles pour la gestion du code source.
Structure des branches dans GitFlow
GitFlow utilise plusieurs types de branches, chacune avec un rôle spécifique :
- master/main : Contient uniquement le code de production stable
- develop : Branche principale de développement où s'intègrent les fonctionnalités
- feature/ : Branches pour développer de nouvelles fonctionnalités
- release/ : Branches pour la préparation des versions à livrer
- hotfix/ : Branches pour les correctifs urgents en production
- support/ : Branches optionnelles pour le support des versions antérieures
Exemple de flux GitFlow
Voici un exemple concret du cycle de vie d'une fonctionnalité avec GitFlow :
- L'équipe travaille sur la branche
develop
- Alice crée une branche
feature/authentification
à partir dedevelop
- Alice termine la fonctionnalité et la fusionne dans
develop
- L'équipe décide de préparer la version 1.0.0
- Bob crée une branche
release/1.0.0
à partir dedevelop
- Bob corrige quelques bugs mineurs dans la branche de release
- La release est fusionnée dans
master
etdevelop
- Un tag
v1.0.0
est créé surmaster
- Un bug critique est découvert en production
- Charlie crée un
hotfix/correction-login
à partir demaster
- Le hotfix est fusionné dans
master
etdevelop
- Un tag
v1.0.1
est créé surmaster
Trunk-Based Development
Le Trunk-Based Development est une approche minimaliste où les développeurs travaillent principalement sur une seule branche, appelée "trunk" (généralement main
ou master
).
Principes du Trunk-Based Development
- Une seule branche principale (trunk) où presque tout le développement a lieu
- Intégration continue avec commits fréquents sur le trunk
- Branches de fonctionnalités de très courte durée (1-2 jours maximum)
- Utilisation de feature toggles pour désactiver le code incomplet
- Déploiement continu ou fréquent depuis le trunk
Exemple de flux Trunk-Based
Voici un exemple concret du cycle de vie d'une fonctionnalité avec Trunk-Based Development :
- L'équipe travaille sur la branche
main
- Alice crée une branche
feature/bouton-partage
à partir demain
- Alice développe la fonctionnalité en 1 jour
- Alice pousse sa branche et crée une Pull Request
- Bob fait la revue de code et approuve
- Les tests automatisés passent avec succès
- Alice fusionne sa branche dans
main
- Le code est automatiquement déployé en production
- Pour une fonctionnalité plus complexe, Charlie utilise un feature toggle
- La fonctionnalité est développée progressivement et fusionnée régulièrement dans
main
- Une fois complète, le toggle est activé en production
Comparaison et choix
Le tableau ci-dessous présente une comparaison entre GitFlow et Trunk-Based Development pour vous aider à choisir la stratégie la plus adaptée à votre contexte :
Critère | GitFlow | Trunk-Based Development |
---|---|---|
Taille d'équipe | Grandes équipes avec coordination formelle | Petites à moyennes équipes agiles |
Type d'application | Applications avec cycles de release planifiés | Applications web/SaaS avec déploiement continu |
Maintenance | Support de multiples versions en production | Focus sur la dernière version |
Cadence de livraison | Planifiée et moins fréquente | Continue et très fréquente |
Complexité | Complexe avec nombreuses branches | Simple avec peu de branches |
Prérequis techniques | Moins de dépendance aux tests automatisés | Nécessite une bonne couverture de tests |
Validation | Processus formel et multiple | Validation rapide par revue et tests |
Focus | Stabilité et planification | Rapidité et agilité |
Courbe d'apprentissage | Plus difficile à maîtriser | Plus simple à adopter |
Structure du code | Peut fonctionner avec tout type de code | Nécessite une architecture modulaire |