Le choix du workflow Git impacte directement la cadence de déploiement, la fréquence des conflits et la charge cognitive de l’équipe. Il n’existe pas de workflow universel — le bon choix dépend de la taille de l’équipe et de la fréquence de déploiement souhaitée.
GitFlow : pour les projets avec des releases cadencées
GitFlow maintient plusieurs branches longue durée : main, develop, des branches release/ et hotfix/.
# Nouvelle feature
git checkout develop
git checkout -b feature/payment-stripe
# ... développement ...
git checkout develop
git merge --no-ff feature/payment-stripe
git branch -d feature/payment-stripe
# Préparer une release
git checkout -b release/1.3.0 develop
# ... corrections de dernière minute ...
git checkout main
git merge --no-ff release/1.3.0
git tag -a v1.3.0
git checkout develop
git merge --no-ff release/1.3.0
Adapté pour : applications mobiles (releases App Store/Play Store), librairies avec versioning sémantique, équipes qui maintiennent plusieurs versions en production simultanément.
Problèmes : les branches feature longues créent des gros merge conflicts, le workflow est complexe pour les petites équipes, difficile de déployer fréquemment.
Trunk-based Development : pour le déploiement continu
Une seule branche principale (main/trunk). Les features sont développées sur des branches éphémères (1-3 jours max) et mergées directement dans main.
# Feature branch éphémère — maximum 2-3 jours
git checkout -b feat/add-pagination
# ... développement focalisé ...
git push origin feat/add-pagination
# → Pull Request → Review → Merge vers main → Déploiement automatique
Avec trunk-based, main est toujours déployable. Pour ça :
- Les tests CI/CD doivent passer avant tout merge
- Les features incomplètes sont cachées derrière des feature flags
Feature flags : déployer sans exposer
# Un feature flag permet de déployer du code sans l'activer
from flagsmith import Flagsmith
flagsmith = Flagsmith(environment_key=os.environ['FLAGSMITH_KEY'])
def checkout(user_id: str):
flags = flagsmith.get_identity_flags(user_id)
if flags.is_feature_enabled("new-checkout-flow"):
return new_checkout() # nouveau code déployé mais caché
else:
return old_checkout() # ancien code
Avec des feature flags, vous pouvez merger des features incomplètes dans main, les activer progressivement (10% des utilisateurs, puis 50%, puis 100%) et les désactiver immédiatement si un problème apparaît.
Choisir son workflow
| Contexte | Recommandation |
|---|---|
| Startup, déploiement plusieurs fois par jour | Trunk-based |
| Équipe > 20 devs avec features longues | Trunk-based + feature flags |
| Application mobile avec releases mensuelles | GitFlow |
| Librairie open source avec semantic versioning | GitFlow |
| Petite équipe (<10), cadence hebdomadaire | GitHub Flow (main + branches éphémères) |
Notre formation Git couvre les workflows d’équipe avec des exercices sur des scénarios réels.