Ce chapitre présente les notions dans un ordre progressif. Les commandes illustrent le fonctionnement ; les manipulations guidées sont regroupées dans les TP.
4.1 Un workflow commun à l’équipe
Les commandes ne suffisent pas : une équipe définit la branche de référence, le circuit de revue, les tests requis et les conditions de livraison. Le modèle doit limiter les divergences et rendre claire la destination de chaque modification.
4.2 Git Flow : préparer des versions
| Branche | Origine | Destination / rôle |
|---|---|---|
main | Versions validées. | Historique stable et tags de versions. |
develop | Base de développement. | Intègre les fonctionnalités de la prochaine version. |
feature/* | develop | Retour vers develop après revue. |
release/* | develop | Préparation, tests et corrections ; retour vers main et develop. |
hotfix/* | main | Correction urgente ; retour vers main et develop pour conserver le correctif. |
Exemple : feature/auth rejoint develop ; release/1.0.1 stabilise la livraison ; un tag sur main repère la version publiée. La double réintégration évite qu’un correctif de production disparaisse de la future version.
4.3 GitHub Flow : changements courts
Une branche principale déployable, des branches courtes issues de main, puis une PR relue et testée. Une fois intégrée, la branche de travail peut être supprimée. La simplicité du modèle repose sur des checks fiables et des changements de taille maîtrisée.
GitHub Flow ne rend pas le déploiement automatique à lui seul : l’équipe décide quand le code validé est livré. Une branche main verte n’est pas une garantie absolue d’absence de bug.
4.4 Choisir selon les contraintes
| Critère | Git Flow | GitHub Flow |
|---|---|---|
| Cadence | Versions regroupées et phase de stabilisation. | Petits changements intégrés fréquemment. |
| Structure | Plusieurs branches avec rôles distincts. | main et branches de travail. |
| Coût | Coordination et réintégrations plus nombreuses. | Exige revue et tests rapides et fiables. |
Le nombre de branches n’est pas un objectif. Choisir un processus compatible avec la cadence, les versions maintenues et les validations nécessaires ; le documenter et le faire respecter.
4.5 Du branching au processus complet
- Revue : responsables et nombre de validations adaptés à l’équipe.
- Tests : checks automatisés avant intégration.
- Livraison : événement déclencheur, artefact, environnement et approbation éventuelle.
- Traçabilité : issue, PR, commit, tag et version livrée reliés entre eux.
Une PR peut être approuvée mais bloquée par un check ; un check réussi peut ne pas suffire si une revue est requise. Ces contrôles sont complémentaires.
4.6 Workflow de livraison et responsabilités
Le choix entre Git Flow, GitHub Flow ou une variante interne dépend du rythme de livraison, du nombre de versions maintenues et des contraintes de validation. L'objectif n'est pas de multiplier les branches mais de rendre le chemin vers la production explicite.
| Moment | Réflexe d'équipe |
|---|---|
| Début du changement | Partir d'une branche de référence à jour et créer une branche courte et identifiable. |
| Avant PR | Relire le diff, tester localement, vérifier qu'aucun secret ou fichier parasite n'est inclus. |
| PR | Décrire intention, risque, tests et impact de déploiement ; laisser les checks automatisés s'exécuter. |
| Merge | Utiliser la stratégie décidée par l'équipe (merge, squash ou rebase) de façon cohérente. |
| Après livraison | Tag/release si nécessaire, supprimer les branches temporaires et surveiller le résultat du déploiement. |
main représente la production, une PR fusionnée sur main peut devenir l'événement qui déclenche le pipeline de livraison. Cette convention doit être protégée par les règles du dépôt et les contrôles CI.