01 - Branching stratégies : choisir son workflow
Ce que tu vas apprendre
- Les quatre stratégies de branching les plus courantes
- Leurs avantages et inconvenients concrets
- Laquelle choisir selon la taille de ton équipe
Prerequisites
Pourquoi c'est un vrai sujet
Quand tu bosses seul, la stratégie de branching c'est simple : tu commites sur main et tu push. Quand tu es deux ou trois devs, ca se complique. Sans convention, chacun fait a sa sauce. Un créé des branches nicolas/fix-header, l'autre bugfix-login, le troisieme commite directement sur main. L'historique devient incomprehensible et les merge requests se marchent dessus.
J'ai vecu ca. Avant de poser des regles claires, mon historique GitLab ressemblait a un arbre genealogique de famille recomposee. Alors on a choisi un workflow et on s'y est tenu. Ca a tout change.
GitFlow : le mastodonte
Invente par Vincent Driessen en 2010, GitFlow est la stratégie la plus connue. Le principe : deux branches permanentes (main et develop) et trois types de branches temporaires (feature/*, release/*, hotfix/*).
Le cycle ressemble a ca :
bash# Tu travailles sur une feature
git checkout develop
git checkout -b feature/add-search
# Tu finis ta feature, tu merges dans develop
git checkout develop
git merge feature/add-search
# Quand develop est pret pour une release
git checkout -b release/1.2.0
# Tests, bugfixes sur la release branch...
git checkout main
git merge release/1.2.0
git tag v1.2.0
# Hotfix en prod
git checkout main
git checkout -b hotfix/fix-crash
# Fix...
git checkout main
git merge hotfix/fix-crash
git checkout develop
git merge hotfix/fix-crash
C'est rigoureux. Chaque branche a un rôle precis. Tu sais exactement ce qui est en prod (main), ce qui est en dev (develop), et ce qui part bientot (release).
Le problème : c'est lourd. Pour une équipe de 2-3 devs qui deploie en continu, maintenir develop et main en parallèle, c'est de la charge mentale pour rien. Les merge entre branches permanentes creent des commits de merge en serie. Et si tu deploies a chaque push sur main via GitLab CI, la branche release ne sert a rien.
GitFlow convient aux projets avec des cycles de release fixes (une release tous les mois, par exemple) et des équipes de 10+ devs. Si tu livres une app mobile avec des versions numerotees, ca a du sens.
GitHub Flow : simple et efficace
GitHub Flow est drastiquement plus simple. Tu as main. Tu créés des branches de feature. Tu ouvres une merge request. Quelqu'un review. Tu merges. Tu deploies. C'est tout.
bash# Nouvelle feature
git checkout main
git pull
git checkout -b feat/user-profile
# Tu bosses, tu commites
git add .
git commit -m "feat: add user profile page"
git push -u origin feat/user-profile
# Tu ouvres une merge request sur GitLab
# Apres review et CI verte, tu merges dans main
# Le deploy se lance automatiquement
Pas de branche develop. Pas de branche release. main est toujours deployable. Si tu casses quelque chose, tu fais un hotfix direct sur une nouvelle branche depuis main.
C'est le workflow que j'utilise pour paltemps.fr et pour la plupart de mes projets. Avec deux juniors dans l'équipe, la simplicité est un avantage énorme. Moins de branches a gerer, moins de confusion.
Trunk-based development : pour les équipes disciplinees
En trunk-based, tout le monde commite sur main (le "trunk"). Pas de branches longues. Si tu as besoin d'une feature qui prend du temps, tu utilises des feature flags pour la cacher en prod.
bash# Tu commites directement sur main
git checkout main
git pull --rebase
# ... modifications ...
git add .
git commit -m "feat: add search behind flag"
git push
C'est la stratégie de Google, Facebook, et pas mal de grosses boîtes avec des équipes seniors et une CI extremement solide. Chaque commit sur main est teste et déployé automatiquement. Les feature flags permettent de livrer du code incomplet sans que les utilisateurs le voient.
Mon avis honnete : avec des juniors qui oublient de lancer les tests avant de push, c'est une recette pour la catastrophe. Il faut une couverture de tests excellente et une CI qui bloque tout commit cassant. Si tu en es la, fonce. Sinon, c'est premature.
GitLab Flow : le compromis avec les environnements
GitLab Flow ajoute des branches d'environnement. Tu as main pour le dev, staging pour les tests, production pour la prod. Le code remonte : main -> staging -> production.
bash# Feature branch classique
git checkout main
git checkout -b feat/notifications
# Apres merge dans main, tu promeus vers staging
git checkout staging
git merge main
# Apres validation sur staging, tu promeus vers prod
git checkout production
git merge staging
Ca marche bien si tu as besoin de tester sur un environnement de staging avant la prod. Mais ca ajoute de la complexité. Pour une petite équipe, c'est souvent du bruit en plus.
Mon choix pour une petite équipe
Si tu es 2-3 devs et que tu deploies via GitLab CI a chaque push sur main : GitHub Flow. Sans hesiter.
GitFlow est overkill. Tu vas passer plus de temps a gerer tes branches qu'a écrire du code. Trunk-based demande une discipline et une CI que tes juniors n'ont pas encore. GitLab Flow se justifie si tu as un vrai staging, mais souvent un preview deployment par merge request suffit.
Conventions de nommage
Quel que soit ton workflow, nomme tes branches avec un prefixe :
bashfeat/add-search-bar # nouvelle fonctionnalite
fix/login-redirect # correction de bug
chore/update-deps # maintenance
refactor/split-user-service # refactoring
docs/api-endpoints # documentation
Ca colle avec les conventional commits qu'on verra plus tard. Et ca rend l'historique lisible d'un coup d'oeil dans GitLab.
Protege ta branche main dans les settings du projet (Settings > Repository > Protected branches). Interdis le push direct. Oblige les merge requests. Oblige au moins une approbation. Ca t'evitera l'anecdote du force push que j'ai racontee dans l'introduction.
Article précédent : 00 - Introduction Article suivant : 02 - Rebase vs merge