Choisir une stratégie de branchement

Le développement basé sur le trunk pousse le principe « les branches doivent être éphémères » à sa conclusion logique : les branches vivent des heures, pas des jours. Les ingénieurs poussent de petits changements incrémentaux vers main plusieurs fois par jour, en utilisant des feature flags pour cacher le travail incomplet aux utilisateurs.

Les avantages sont réels. Les problèmes d'intégration apparaissent immédiatement parce que les branches ne s'éloignent jamais beaucoup de main. Les exécutions CI sont rapides parce que le diff est petit. Il n'y a pas de « jour de fusion » parce que la fusion est continue. Les équipes pratiquant le développement basé sur le trunk rapportent des fréquences de déploiement 4 à 8 fois plus élevées que les équipes utilisant des branches à longue durée de vie.

Les exigences sont également réelles. Le développement basé sur le trunk exige une excellente CI (les tests doivent être rapides et fiables), une infrastructure de feature flags robuste (vous devez livrer du code incomplet en toute sécurité), et une confiance élevée entre ingénieurs (aucune barrière de revue signifie que l'auteur porte l'entière responsabilité). Pour une équipe de 4 personnes avec une CI solide et une base de code partagée, c'est souvent la façon la plus rapide de travailler. Pour une équipe de 30 personnes avec une couverture de tests inégale, c'est une recette pour une branche main cassée.

C'est GitHub Flow poussé un cran plus loin — moins de branches, durées de vie plus courtes, plus de dépendance aux flags qu'à l'isolation.

GitHub Flow est le bon défaut pour la plupart des équipes, et il vaut la peine de comprendre pourquoi. Le modèle entier tient en trois règles : main est toujours déployable, chaque changement se fait sur une branche éphémère, et les branches fusionnent vers main via des PR révisées. C'est tout.

Il n'y a pas de branche develop, pas de branche release, pas de branche hotfix. Une branche par changement, une PR par branche, une fusion vers main. Quand main reçoit une nouvelle fusion, vous pouvez la déployer — manuellement, automatiquement, ou selon un calendrier. La simplicité est la fonctionnalité.

GitHub Flow fonctionne parce qu'il correspond à la façon dont la plupart des équipes produit livrent réellement : continuellement, en petits incréments, sans la surcharge de coordonner des trains de release. Une branche de fonctionnalité vit un jour ou deux, est révisée, fusionne, et est livrée. Si elle casse quelque chose, vous revertez et corrigez. La boucle de rétroaction est serrée.

Là où GitHub Flow peine, c'est quand vous devez maintenir plusieurs versions de production simultanément (vous livrez v2.3 mais devez corriger v2.1 pour un client), ou quand votre processus de déploiement est lent et coûteux (rendant « juste revenir en arrière » irréaliste). Ces scénarios nécessitent un modèle de branchement plus structuré — mais ce sont l'exception, pas la règle.

GitFlow a été conçu pour un monde où les logiciels étaient livrés sur CD — versions numérotées, longs cycles QA, plusieurs versions supportées sur le terrain. Si c'est votre monde (applications desktop, systèmes embarqués, logiciels d'entreprise avec support de version contractuel), la structure de GitFlow justifie sa complexité.

Le modèle ajoute plusieurs branches à longue durée de vie : develop (intégration), release/* (stabilisation), hotfix/* (correctifs d'urgence en production), et main (état de production). Les fonctionnalités se branchent depuis develop, les releases bifurquent depuis develop quand une version est « complète en fonctionnalités », et les hotfixes se branchent directement depuis main.

Pour les équipes déployant une application web — ce qui est la plupart des équipes lisant ce cours — GitFlow est presque certainement excessif. La branche develop ajoute une couche d'indirection entre votre travail et la production sans bénéfice proportionnel. Les branches de release n'ont de sens que si vous avez une barrière QA formelle entre « code complet » et « livré ». Les branches de hotfix sont inutiles quand déployer un correctif prend des minutes, pas des semaines.

GitFlow n'est pas mauvais. Il est conçu pour un contexte spécifique. Si vous n'avez pas ce contexte (plusieurs versions supportées, déploiements lents, barrières de release formelles), vous payez la taxe de complexité sans le bénéfice. Commencez avec GitHub Flow. Vous pouvez toujours ajouter de la structure plus tard si la situation l'exige — mais vous en aurez rarement besoin.