GitDevOpsWorkflowDev

Git workflow en équipe : GitFlow vs Trunk-based Development

28 avril 2026 · Sphinx-Digital

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

ContexteRecommandation
Startup, déploiement plusieurs fois par jourTrunk-based
Équipe > 20 devs avec features longuesTrunk-based + feature flags
Application mobile avec releases mensuellesGitFlow
Librairie open source avec semantic versioningGitFlow
Petite équipe (<10), cadence hebdomadaireGitHub Flow (main + branches éphémères)

Notre formation Git couvre les workflows d’équipe avec des exercices sur des scénarios réels.