Choisir une stratégie de branches
Objectif : Sélectionner une stratégie de branches cohérente avec le rythme des livraisons, les versions prises en charge et la taille de l’équipe.
Quand plusieurs personnes font évoluer un même dépôt, des branches trop longues ou des branches de version mal choisies compliquent les livraisons. Vous devez décider où préparer chaque changement et comment prendre en charge les versions déjà publiées. Cette décision doit correspondre au rythme réel du site devenu produit, pas à une organisation théorique.
La leçon précédente vous a permis de cartographier les changements et d’attribuer les vérifications. Vous allez maintenant choisir la forme des branches qui portera ces changements, selon que l’équipe livre une seule version active ou doit entretenir plusieurs versions simultanément.
Deux modèles pour organiser les branches
Une branche de fonctionnalité isole un changement en cours, par exemple l’ajout d’une page ou la mise à jour d’une procédure du guide. Elle part de la branche principale et sert à travailler sans exposer une modification inachevée aux autres contributions. Dans le flux GitHub, ces branches restent généralement de courte durée : le travail est proposé à la revue, puis intégré à la branche principale quand il est prêt.
Le flux GitHub convient souvent à une équipe qui livre régulièrement une version principale, sans devoir maintenir plusieurs versions publiques en parallèle. Chaque proposition concentre un changement compréhensible et peut être vérifiée indépendamment. Une fois intégrée, la branche de fonctionnalité n’a plus besoin d’être conservée comme ligne de développement durable.
git switch main
git switch -c feature/guide-recuperation
# Modifier et vérifier les fichiers du projet
git add index.html README.md
git commit -m "Ajouter le guide de récupération"Ces commandes créent une branche de travail à partir de main, puis enregistrent les fichiers concernés dans un commit. Le nom de branche de l’exemple illustre une intention, mais la convention exacte de nommage sera fixée plus tard. Le commit ne fusionne rien à lui seul : la proposition et sa revue appartiennent au processus d’équipe.
Quand choisir des branches de version
Une branche de maintenance porte des corrections destinées à une version déjà publiée, tandis que la branche principale continue d’accueillir l’évolution du produit. Une équipe peut en avoir besoin si des utilisateurs restent temporairement sur une ancienne version et attendent encore des correctifs. Dans un flux par branches de version, des branches durables représentent ces lignes prises en charge, par exemple release/1.x et release/2.x.
Ce modèle est utile lorsque les dates de livraison sont espacées, que plusieurs versions doivent recevoir des correctifs, ou que les déploiements ne peuvent pas suivre chaque changement de la branche principale. Il ajoute toutefois des responsabilités : il faut décider quelles corrections sont répercutées sur quelles versions, suivre leur durée de prise en charge et éviter que les branches divergent sans raison. Pour un site déployé continuellement avec une seule version active, ces coûts ne sont généralement pas justifiés.
| Contexte de l’équipe | Stratégie à privilégier | Conséquence pratique |
|---|---|---|
| Une version active, livraisons fréquentes | Flux GitHub avec branches de fonctionnalité courtes | Les changements convergent vers la branche principale au fil des revues. |
| Plusieurs versions publiées à corriger | Branches de version avec branches de maintenance | Les correctifs ciblent explicitement les versions encore prises en charge. |
| Petite équipe, faible besoin de compatibilité historique | Flux GitHub simplifié | Moins de branches durables à synchroniser et à surveiller. |
| Équipe ou produit avec engagements de support par version | Branches de version | Il faut documenter la durée de support et le chemin de chaque correctif. |
Appliquer le choix au dépôt du site
Pour le dépôt fil rouge, retenez le flux GitHub tant que l’équipe publie une seule version active du site. Les modifications d’index.html, style.css, README.md ou .gitignore peuvent être isolées dans des branches de fonctionnalité courtes, puis proposées à la revue. La cartographie établie précédemment aide à préciser le périmètre et les contrôles, sans imposer de branche de version pour chaque type de fichier.
Réévaluez ce choix si le produit commence à garantir des correctifs pour des versions antérieures pendant que la branche principale évolue. Dans ce cas, définissez quelles versions restent prises en charge et qui valide les correctifs qui les concernent. Le flux retenu ne fixe pas encore les modalités d’intégration : les règles d’historique et de protection seront traitées dans une prochaine leçon.
À retenir
- Utilisez des branches de fonctionnalité courtes pour isoler les changements proposés à la branche principale.
- Choisissez un flux GitHub si l’équipe livre une seule version active de façon régulière.
- Adoptez des branches de version lorsqu’il faut corriger durablement plusieurs versions publiées.
- Documentez les versions prises en charge et le parcours des correctifs avant de créer des branches durables.