Stratégies de branches

Comprendre pourquoi on branche, et ce que coûte une branche qui vit trop longtemps.

Guide≈ 11 min de lectureVérifié en partieLecture

En bref

Comprendre pourquoi on branche, et ce que coûte une branche qui vit trop longtemps.
Connaître les stratégies de référence : trunk-based, GitFlow, GitHub Flow, GitLab Flow, release branches, branches par version produit.
Savoir transposer au monde TFVC (Main/Dev/Release, fusions, baseless) et aux snapshots de release.
Utiliser les feature toggles pour découpler fusion et livraison.
Choisir une stratégie pour un projet SQL/BI, avec notes /5 par contexte.

Sur cette page

Pourquoi brancher
Le coût d'une branche
Trunk-based development
GitFlow
GitHub Flow
GitLab Flow
Branches de release
Branches par version produit
TFVC et les branches standard
Feature toggles
Stratégies pour SQL et BI
Notes par contexte
Conventions et protections
Pièges
Voir aussi

Niveau : 🟢→🔴

Pourquoi brancher#

🟢 Niveau novice

Une branche isole une ligne de développement : on travaille sur une évolution sans perturber le code stable. On branche pour trois raisons : isoler un travail en cours (fonctionnalité, correctif), stabiliser (préparer une version pendant que le développement continue), maintenir (corriger une version déjà livrée). Un projet sans branche travaille sur un tronc unique ; un projet sur-branché passe son temps à fusionner.

Le coût d'une branche#

🟢 Niveau novice

Brancher est gratuit ; fusionner ne l'est pas. Le coût d'une fusion croît avec la durée de divergence et le nombre de fichiers touchés des deux côtés. Deux effets :

Conflits textuels : mêmes lignes modifiées.
Conflits sémantiques : le code fusionne sans conflit mais ne fonctionne plus (renommage d'une colonne côté SQL, nouvelle utilisation de l'ancienne colonne côté rapport). Les plus coûteux, car aucun outil ne les signale.

🧪 Exemple chiffré (ordre de grandeur)

Une branche de fonctionnalité de 3 jours accumulant 12 fichiers modifiés sur un tronc actif se fusionne en 15 à 30 minutes. La même branche laissée 6 semaines en demande plusieurs heures, avec risque de régression. La relation n'est pas linéaire, c'est le message à retenir.

✅ Bonne pratique

Règle de pouce : intégrer au tronc au moins une fois par jour ou tous les deux jours ; toute branche de plus d'une semaine doit être justifiée.

Trunk-based development#

🟡 Niveau pratique

Principe : tout le monde intègre sur un tronc unique (main), via branches très courtes (heures à 1-2 jours) ou directement. Les fonctions inachevées sont masquées par des feature toggles. Une branche de release n'est coupée que pour stabiliser/maintenir.

Pré-requis : CI rapide et fiable, tests automatisés, revue légère (ou programmation en binôme), discipline de petits commits. C'est la pratique la plus associée, dans la littérature sur la performance de livraison (travaux DORA, Accelerate), à de meilleurs indicateurs de livraison.

Forces : fusions minimes, intégration continue réelle, visibilité. Limites : exige maturité des tests ; difficile avec des livraisons en kits distincts à longue maintenance sans branches de release ; inconfortable quand le tronc ne peut pas casser (pas de CI fiable).

GitFlow#

🟡 Niveau pratique

Modèle publié par Vincent Driessen en 2010 : branches permanentes master (production, notée main dans le schéma) et develop (intégration), branches temporaires feature/*, release/*, hotfix/*.

main     ──●────────────────●─────────●── (tags v1.0, v1.1)
            \              /         /
release      \      ●──●──●         /
              \    /               /
develop  ──●───●──●──●──●───●──●──●────
              \   /  \       /
feature        ●─●    ●──●──●

Forces : cadre clair pour des versions planifiées à cadence lente, maintenance parallèle de plusieurs versions. Limites : lourd (deux branches permanentes, fusions multiples), retarde l'intégration, déconseillé par son propre auteur pour les applications livrées en continu (note ajoutée par l'auteur à son article en 2020). Reste pertinent pour des produits versionnés livrés en kits.

GitHub Flow#

🟡 Niveau pratique

Très simple : main est toujours déployable ; on crée une branche courte, on ouvre une pull request, on relit, on teste, on fusionne, on déploie. Pas de develop, pas de release branches. Adapté à une application en déploiement continu et à une équipe petite à moyenne. Insuffisant quand il faut maintenir plusieurs versions installées chez des clients.

GitLab Flow#

🟡 Niveau pratique

Variante : branches d'environnement (staging, production) ou branches de release (release/9.1) en aval de main. Les changements vont de main vers l'aval uniquement (« upstream first » : on corrige d'abord sur main, puis on rétro-porte). Compromis entre simplicité de GitHub Flow et nécessité de versions maintenues. Souvent le meilleur point de départ pour une équipe produit.

Branches de release#

🟡 Niveau pratique

Une branche de release (release/9.1) est coupée quand la version est « presque prête ». Sur elle : seulement des correctifs (pas de nouvelles fonctionnalités). Pendant ce temps, main continue vers la version suivante. Règle d'or : corriger sur la plus ancienne branche concernée, fusionner vers l'avant (ou « upstream first » puis rétro-portage par cherry-pick avec -x si les modèles divergent).

Cycle : main → release/9.1 (coupe) → durcissement, correctifs → tag v9.1.0 → correctifs ultérieurs 9.1.1, 9.1.2 sur la même branche → fin de support.

Branches par version produit#

🟡 Niveau pratique

Pour un produit livré à des clients qui restent sur des versions différentes (typiquement 8.0, 8.1, 9.0, 9.1…), chaque version maintenue a sa branche (ou son dossier), de vie longue. Deux variantes :

Variante	Principe	Avantage	Inconvénient
Branches de maintenance vivantes	`release/9.0`, `release/9.1` reçoivent des correctifs ; fusion vers l'avant	Une source de vérité par version, historique continu	Fusions en cascade (9.0 → 9.1 → main), risque d'oubli
Instantanés (« snapshots ») figés	À chaque livraison, une copie de l'arborescence est archivée (dossier `Releases/9.1/`) ; les évolutions n'y entrent plus que par correctifs explicites	Reproduction simple d'une version, zéro surprise	Duplication ; correctifs recopiés manuellement ; dérive silencieuse entre snapshots

Le modèle « instantanés dans des dossiers » est courant en TFVC (les branches y sont des dossiers). Son défaut : aucune relation de fusion entre les dossiers si on les a copiés au lieu de les brancher ; chaque correctif multi-versions est alors une opération manuelle de cherry-pick à la main (ou fusion baseless), sans trace de ce qui est déjà propagé. Remède : garder la relation de branche (branches TFVC déclarées ou branches Git), et tenir une matrice de propagation des correctifs (quel défaut corrigé dans quelles versions).

🧪 Exemple (fil rouge)

Un correctif de calcul d'un indicateur est découvert en 9.1. Il doit atteindre 9.0, 8.1 et main. Avec des branches Git : commit sur release/8.1, fusion vers 9.0, 9.1, main : un seul commit, tracé. Avec des dossiers copiés : quatre modifications manuelles, quatre risques d'oubli ou de divergence, quatre tests de recette.

Matrice de propagation minimale (à tenir dans le ticket ou la page de livraison) :

Défaut	8.1	9.0	9.1	main
#A — calcul couverture	✅ CS/commit	✅	✅	✅
#B — libellé multilingue	n/a	✅	✅	✅
#C — jointure client	❌ non applicable (autre modèle)	✅	✅	✅

✅ Bonne pratique

Notez explicitement « non applicable » avec la raison ; un défaut absent d'une version doit être un choix, pas un oubli.

TFVC et les branches standard#

🟡 Niveau pratique

Le guide Microsoft historique (Branching and Merging Guide, Visual Studio ALM Rangers) décrit des modèles : Main Only (tronc unique) ; isolation du développement (Main + Dev) ; isolation des fonctionnalités (Main + Feature) ; isolation des releases (Main + Release) ; isolation de la maintenance et des releases (Servicing + Release). Le modèle « promotion de code » n'y est plus recommandé. En résumé :

$/Projet
  Main                      (intégration stable)
  Dev                       (développement courant)
    Feature-ABC             (branche courte)
  Releases
    R9.0   R9.1             (maintenance)

Règles du modèle standard :

Flux ascendant/descendant : Dev → Main (RI, reverse integration), Main → Dev (FI, forward integration). Une fusion latérale (R9.0 → R9.1) n'est pas autorisée sans passer par Main, sauf baseless.
Intégrer souvent vers Dev pour réduire la dérive ; réintégrer par lots testés vers Main.
Branches de release créées depuis Main au moment du gel ; correctifs sur la release puis fusionnés vers Main (reverse integration) pour ne pas régresser.
Merges baseless (tf merge /baseless) : hors relation de branche ; à réserver aux cas particuliers (voir 03). Chaque merge baseless est un coup de dé sur les conflits.

Notes /5 de la structure TFVC « Main + Releases » pour un produit en maintenance sur 4 versions (équipe de 5-15) :

Critère	Note	Justification
Isolation d'une version	5/5	Dossier distinct, droits par dossier
Propagation d'un correctif	2/5	Fusions manuelles, baseless si copie
Lisibilité	4/5	Arbre de dossiers visible
Coût d'une nouvelle release	3/5	Branch serveur simple, mais surface croissante
Rétro-fusion et traçabilité	3/5	Visualisation de la hiérarchie dans Visual Studio

Feature toggles#

🔴 Niveau expert

Un feature toggle (drapeau de fonctionnalité) permet de fusionner du code inachevé sans l'activer. Il découple déploiement et mise en service. Types : release toggle (court terme, masque une fonction en cours), ops toggle (désactiver en urgence), experiment toggle (A/B), permission toggle (selon client).

Application data/BI :

Paramètre _Parameter en base qui active un nouveau calcul ou une nouvelle jointure ; la même procédure contient les deux chemins, choisis par paramètre (testés des deux côtés) ; on retire l'ancien chemin et le paramètre une fois validé.
Mesures DAX en parallèle (ancienne/nouvelle) avec bascule via paramètre de champ ou groupe de calcul, sans supprimer l'ancienne (les rapports clients restent liés à l'existante).
Pages de rapport masquées pour une fonction en recette (rappel : « masquée » n'est pas « inaccessible »).

Coût : dette de toggles (code mort, combinatoire de tests). Chaque toggle porte une date de suppression et un propriétaire.

⚠️ Piège

Symptôme : plus personne ne sait quels paramètres sont actifs chez quel client ; cause : toggles jamais retirés. Remède : registre des toggles, revue trimestrielle, suppression planifiée.

Stratégies pour SQL et BI#

🔴 Niveau expert

Particularités qui changent la réponse :

Le déploiement n'est pas le code : un schéma de base porte un état (données, tables existantes) ; deux branches qui modifient la même table produisent des migrations conflictuelles même si les fichiers ne se touchent pas. Voir 06.
Les rapports sont couplés au modèle : une colonne renommée en SQL casse la couche sémantique et les rapports. Branchez en tranches verticales (SQL + modèle + rapport ensemble) dans un monorepo, ou coordonnez les PR.
Fichiers BI mal fusionnables (.pbix) : format PBIP/TMDL pour permettre la fusion (voir 06).
Plusieurs versions installées chez des clients : branches de maintenance ou instantanés ; kits d'installation par version.
Recette métier : la validation sur chiffres demande des environnements ; la branche « release » doit avoir son environnement de test.
Intégration continue partielle : on ne peut pas toujours reconsolider tout le datamart à chaque commit ; prévoir un test de chargement partiel (échantillon) sur chaque PR et la consolidation complète à la release (CI/CD pour la data).

Recommandation générale pour une équipe de 5 à 30 personnes sur un datamart + BI en versions maintenues : trunk-based « allégé » (branches courtes, PR) + branches de release par version maintenue + corriger d'abord sur la plus ancienne branche concernée et fusionner vers l'avant + tags signés + matrice de propagation.

Notes par contexte#

🔴 Niveau expert

Appréciations /5 ; critère : adéquation de la stratégie à chaque contexte (voir NOTATION). Lecture : une note basse n'est pas un défaut, c'est un mauvais appariement.

Stratégie	Équipe 3-5, produit unique en continu	Équipe 10-30, versions maintenues (kits)	Projet data/BI, rapports couplés	Équipe novice en GDS	Forte exigence d'audit
Trunk-based	5/5	3/5	3/5 (si CI partielle)	2/5	3/5
GitHub Flow	5/5	2/5	3/5	5/5	3/5
GitLab Flow (release branches)	4/5	5/5	4/5	3/5	4/5
GitFlow	2/5	4/5	3/5	2/5	4/5
Instantanés par dossier (sans relation de branche)	2/5	2/5	2/5	4/5	3/5
TFVC Main/Dev/Release	3/5	4/5	3/5	4/5	4/5

Conventions et protections#

🟡 Niveau pratique

Nommage : feature/<ticket>-<sujet>, fix/<ticket>-<sujet>, release/<version>, hotfix/<version>-<sujet>.
Protections : main et release/* interdisent force-push et suppression ; PR obligatoire avec au moins un relecteur ; build de validation ; liaison à un work item ; résolution des commentaires.
Fusion : squash pour feature courte, merge commit pour conserver la topologie de release, rebase pour historique linéaire. Choisissez une convention par type de branche et documentez-la.
Versionnage : numérotation sémantique MAJEUR.MINEUR.CORRECTIF ; tag annoté (signé) par livraison ; branche de release supprimée seulement à la fin de support.
Durée de vie : suppression automatique des branches de fonctionnalité fusionnées.

Pièges#

🔴 Niveau expert

⚠️ Piège — Branche « Dev » éternelle : la branche d'intégration dérive du tronc ; chaque réintégration devient un projet. Remède : fusionner souvent, ou supprimer Dev.
⚠️ Piège — Cherry-pick sans trace : le même correctif existe sous quatre identifiants ; les fusions ultérieures le re-signalent comme conflit. Remède : -x, matrice de propagation, correction upstream-first.
⚠️ Piège — Release branche « ouverte » : on y glisse des fonctionnalités. Remède : politique « correctifs seulement », contrôle en PR.
⚠️ Piège — Fusion sémantique non vue : tests verts, chiffres faux. Remède : recette sur trois totaux métier avant de tagger.
⚠️ Piège — Mauvais outil pour le problème : GitFlow pour une équipe de 4 en déploiement continu ; GitHub Flow pour 4 versions maintenues.
⚠️ Piège — Dossier Releases/ copié à la main : voir ci-dessus, aucune relation de fusion.

🤖 IA

L'IA aide à rédiger des conventions, générer des scripts de protection de branche (API de la plateforme), suggérer la matrice de propagation à partir de l'historique, et repérer des divergences entre branches (git cherry). Garde-fous : elle ne connaît pas votre politique de support ; la décision de rétro-porter ou non reste humaine ; vérifiez les commandes destructives. Voir IA et outils.

Voir aussi#

✻ Rédigé par Claude Sonnet 5.5