Conçois une stratégie de branches adaptée à une petite équipe

01Pars des contraintes réelles

Taille de l’équipe
Fréquence de livraison
Durée des fonctionnalités
Besoin de staging
Support de plusieurs versions
Exigences de revue et CI
Capacité de rollback

La stratégie répond à ces contraintes. Elle ne doit pas être copiée mécaniquement depuis une organisation plus grande.

02Compare deux modèles

Pour SORIA, dev alimente staging et main reste la branche de production. Les feature branches sont validées mais non déployées.

03Observe le scénario du lab

cd /tmp/soria-git-branches-$USER/strategy
git branch --list
git log --oneline --decorate --graph --all

La branche feature/network-policy part de dev. Dev contient également une évolution de documentation, ce qui oblige à une véritable intégration.

04Intègre la feature dans dev

git switch dev
git merge --no-ff feature/network-policy \
  -m "merge: integrate network policy"
git status --porcelain
git log --first-parent --oneline dev

La feature devient disponible dans la branche d’intégration sans modifier main.

05Prépare une release

git switch -c release/1.0
printf '# Release 1.0\n' > docs/release-1.0.md
git add docs/release-1.0.md
git commit -m "docs: prepare release 1.0"

Une release branch reste courte et n’accepte que préparation, correction de blocage et documentation de livraison.

06Fusionne la release dans main

git switch main
git merge --no-ff release/1.0 -m "merge: release version 1.0"
git merge-base --is-ancestor dev main
git merge-base --is-ancestor release/1.0 main
git log --oneline --decorate --graph --all

07Définis les règles écrites

main
- état déployable en production
- fusion uniquement après validation
- pas de commit direct ordinaire

dev
- état déployable en staging
- reçoit les features validées

feature/*
- une intention
- durée courte
- supprimée après intégration

release/*
- préparation d’une livraison identifiée
- aucune nouvelle fonctionnalité

08Définis la recette de fusion

[ ] branche basée sur la bonne cible
[ ] commits compréhensibles
[ ] diff relu
[ ] tests et CI réussis
[ ] aucun secret ou artefact local
[ ] conflits résolus et vérifiés
[ ] stratégie de rollback connue
[ ] branche supprimable après fusion

09Réduis les branches longues

Une branche longue accumule conflits, changements de contexte et dépendances. Intègre fréquemment la branche cible, découpe le travail et utilise des mécanismes d’activation plutôt que de conserver des développements isolés pendant des semaines.