GitFlow c'est nul, mais on l'a cherché
GitFlow c'est pas un choix technique. C'est un pansement culturel pour les boîtes pas prêtes à livrer comme des grands.
Tout le monde adore parler de Trunk-Based Development comme si c’était la solution miracle universelle, jusqu’au moment où il faut réellement envoyer quelque chose en production sans traîner trois fonctionnalités non validées dans les pattes
Parce que oui, dans le monde merveilleux du TBD, on merge tout sur main, on déploie vingt fois par jour, et tout le monde vit heureux grâce à une CI divine, des feature flags impeccables et une équipe de développeurs qui ne cassent jamais rien (on les cherche encore)
Le problème concret
Dans la vraie vie, la nôtre:
- Les features et les hotfix passent par les mêmes UAT, validées par la QA
- Les UAT testent qu’une version à la fois (magie)
- Tout ce qui entre dans l’environnement UAT est potentiellement éligible pour la production
Et là, ça devient amusant:
- Une feature terminée mais pas encore validée ?
- Un hotfix urgent à livrer ?
- Les deux doivent passer en UAT ?
Félicitations: en TBD tu livres les deux. Parce que tout est dans main. Parce qu’il n’y a rien d’autre. Parce que c’est “moderne”
Et si tu voulais juste déployer le hotfix sans embarquer la feature ? Eh bien… tant pis. TBD te répond que tu aurais dû avoir des feature flags, une discipline de fer et un pipeline de tests E2E sponsorisé par Google
Le problème structurel
Le problème principal est structurel: si la feature et le hotfix partagent le même pipeline UAT, alors un modèle trunk-based ne permet pas de livrer l’un sans l’autre
Et tant que tes QA doivent tester une version unique dans un environnement unique avant prod, le fameux “une seule branche pour les gouverner toutes” se transforme en:
“une seule branche pour bloquer tout le monde”
D’où l’existence, surprise, d’une branche d’intégration (develop, staging, peu importe). Pas par amour du vintage GitFlow, mais juste pour ne pas livrer en prod des trucs que personne n’a validés
Pourquoi GitFlow existe
GitFlow compense des réalités organisationnelles:
- La QA c’est une équipe à part avec une étape de validation
- Les releases c’est toutes les semaines ou tous les mois, pas tous les jours
- Les déploiements en prod ça fait flipper
- Les feature flags ça existe pas ou c’est à moitié fait
- La couverture de tests est trop faible pour faire confiance à la CI
- Le codebase c’est un monolithe bien couplé
Si ton orga a ces caractéristiques, trunk-based va foirer. Tu vas shipper du code pas testé. Tu vas bloquer des hotfixes derrière des features pas validées. Tu vas casser la prod
Donc tu prends GitFlow. Des branches longue durée. Une branche develop comme tampon. Des branches release pour stabiliser. Ça marche. C’est lent, mais ça marche
L’évaluation honnête
Si t’as besoin de GitFlow, demande-toi pourquoi:
“On a besoin d’une branche develop parce que la QA teste avant la prod” → Ton process QA supporte pas la livraison continue
“On a besoin de branches release pour stabiliser” → Ta couverture de tests est pas assez bonne pour shipper depuis main
“On peut pas shipper un hotfix sans des features pas liées” → T’as pas de feature flags, ou ton UAT c’est un goulot d’étranglement
“Les merges sur main c’est risqué” → Ton pipeline de déploiement est pas fiable
Rien de tout ça c’est des problèmes Git. C’est des problèmes d’orga. GitFlow les rend juste vivables
L’approche pragmatique
J’utilise GitFlow-light sur des projets où trunk-based serait suicidaire. Pas parce que j’adore ça. Parce que l’alternative c’est pire
Quand t’as:
- Des gates QA manuelles
- Des cycles de release hebdo
- Un seul environnement UAT
- Zéro infra de feature flags
Alors oui, une branche develop t’évite de shipper de la merde. Une branche release te laisse stabiliser. Les branches hotfix te laissent bypass la queue
C’est optimal ? Non. Ça marche ? Oui
Sortir de GitFlow
GitFlow c’est pas l’objectif. C’est un compromis le temps de régler les vrais problèmes
Pour tuer GitFlow, il te faut:
- Des feature flags pour que le travail incomplet puisse se cacher dans main
- De la couverture de tests pour faire confiance à la CI
- Une CI rapide pour la faire tourner à chaque commit
- Plusieurs environnements UAT ou de la validation en parallèle
- Des changements plus petits pour que les merges restent simples
- L’adhésion culturelle que shipper petit c’est mieux que shipper gros
Ça prend des mois ou des années. C’est pas un changement d’outil. C’est un changement d’organisation
En attendant, GitFlow te permet de livrer. Imparfait, mais tu livres
Le mot de la fin
GitFlow c’est nul. Les merge conflicts c’est nul. La gestion des branches c’est nul. Le drift c’est nul
Mais on a appelé GitFlow parce qu’on était pas prêts pour l’alternative. Faut pas blâmer le pansement pour la blessure
Le problème c’est pas Git. C’est que TBD part du principe que t’as une infra et des process que la plupart des boîtes ont tout simplement pas. Et tant que c’est pas le cas, cette branche develop c’est pas de la pensée legacy, c’est de la survie
Vous avez aimé cet article ? Partagez-le !
