Git Flow vs Trunk-Based Development : choisir sa stratégie de branches

Le modèle de branches n’est pas une décision technique anodine. Il conditionne la fréquence de livraison, la complexité des merges et la qualité des revues de code.

Git Flow : le modèle classique

main ────────────────────────────────── v1.0
                                    /
develop ──────────────────────────
       \        \            /
feature/a  feature/b   release/1.0

Git Flow utilise deux branches permanentes (main, develop) et des branches temporaires pour les features, releases et hotfixes.

Avantages : clair, bien documenté, adapté aux logiciels versionnés avec des cycles de release longs (apps mobiles, logiciels on-premise).

Inconvénients : merge complexes, features qui vivent longtemps en isolation, intégration continue difficile.

GitHub Flow : la version simplifiée

main ──────────────────────────────────
       \         \          \
feature/a  feature/b   hotfix/x
       PR→merge  PR→merge  PR→merge

Une seule branche principale, des feature branches courtes qui mergent directement via Pull Request.

Avantages : simple, adapté aux applications web avec déploiement continu.

Inconvénients : moins de contrôle sur ce qui part en production, nécessite une CI/CD solide.

Trunk-Based Development : l’approche DevOps

Tout le monde commit sur main (ou via des feature branches très courtes de 1-2 jours). Les features incomplètes sont cachées avec des feature flags.

# Feature flag pour une feature en cours
if feature_flags.is_enabled("new-checkout-flow", user):
    return new_checkout(cart)
else:
    return legacy_checkout(cart)

Avantages : intégration continue vraie, détection rapide des conflits, adapté aux équipes avec CI/CD mature.

Inconvénients : nécessite une discipline forte, des tests solides et une culture de feature flags.

Quelle stratégie choisir ?

Notre formation Git couvre les trois modèles avec des exercices pratiques sur des workflows réels.