Workflows Git

Pourquoi adopter un workflow Git ?

Lorsque vous travaillez en équipe, il est essentiel d'adopter un workflow Git cohérent. Sans workflow défini, chaque développeur travaille différemment, ce qui crée du chaos :

• Branches créées n'importe comment
• Conflits difficiles à résoudre
• Difficile de savoir ce qui est en production
• Pas de processus de validation clair

Un bon workflow permet de :

• Organiser le développement : Structure claire pour tous
• Gérer les versions : Facilite la maintenance de plusieurs versions
• Assurer la qualité : Protège le code de production
• Optimiser la collaboration : Processus compris par toute l'équipe

Il existe deux workflows principaux : GitFlow et Trunk-Based Development.

GitFlow

GitFlow est un workflow Git formalisé par Vincent Driessen en 2010. C'est un modèle structuré avec plusieurs types de branches ayant chacune un rôle spécifique.

Structure des branches

GitFlow définit 5 types de branches :

main (ou master)

• Contient uniquement le code de production
• Chaque commit sur main = une version en production
• Protégée : impossible de pusher directement dessus
• Taggée avec des numéros de version (v1.0.0, v1.1.0, etc.)

develop

• Branche principale de développement
• Intègre toutes les features terminées
• Représente la prochaine version en préparation
• Toujours prête à être déployée en test

feature/*

• Branches pour développer de nouvelles fonctionnalités
• Créées depuis develop
• Mergées dans develop une fois terminées
• Exemples : feature/user-authentication, feature/dark-mode

release/*

• Branches pour préparer une nouvelle version
• Créées depuis develop
• Permettent de figer les features et corriger les bugs de dernière minute
• Mergées dans main ET develop
• Exemples : release/1.0.0, release/2.1.0

hotfix/*

• Branches pour les corrections urgentes en production
• Créées depuis main
• Mergées dans main ET develop
• Exemples : hotfix/critical-login-bug, hotfix/security-patch

Schéma GitFlow

main      → v1.0.0 ────────────────→ v1.1.0 (hotfix) ─→ v2.0.0
              ↓                          ↑                 ↑
develop   →   * ─→ * ─→ * ─→ * ─→ * ────┘                 │
              ↓         ↑         ↓                        │
feature/X →   * ─→ * ──┘          └─→ * ─→ * ─────────────┘
                                      ↓
release/2.0.0 →                       * ─→ * ─────────────┘

Avantages

• Structure claire : Chaque type de branche a un rôle défini
• Gestion de versions : Facile de maintenir plusieurs versions
• Processus formel : Adapté aux grandes équipes
• Releases planifiées : Idéal pour des cycles de release fixes

Inconvénients

• Complexe : Beaucoup de branches à gérer
• Overhead : Processus lourd pour de petites équipes
• Lent : Les features mettent du temps avant d'arriver en production
• Conflits : Les branches de longue durée créent plus de conflits

Utilisez GitFlow si :

• Vous avez une grande équipe (10+ développeurs)
• Vous avez des cycles de release planifiés (ex: une version tous les mois)
• Vous devez maintenir plusieurs versions en production
• Vous développez des applications mobiles (App Store/Play Store)
• Vous avez besoin d'un processus formel de validation

N'utilisez PAS GitFlow si :

• Vous êtes une petite équipe (< 5 développeurs)
• Vous faites du déploiement continu (plusieurs fois par jour)
• Vous développez une application SaaS (une seule version en production)
• Vous voulez de l'agilité et de la rapidité

Trunk-Based Development (TBD)

Trunk-Based Development est une approche minimaliste où les développeurs travaillent principalement sur une seule branche appelée trunk (généralement main).

Principes du TBD

1. Une seule branche principale : Le trunk (main)
2. Commits fréquents : Plusieurs fois par jour sur le trunk
3. Branches de courte durée : 1-2 jours maximum
4. Feature toggles : Désactiver le code incomplet
5. Déploiement continu : Déployer fréquemment depuis le trunk
6. Tests automatiques : CI/CD obligatoire

Schéma TBD

main      → A → B → C → D → E → F → G → H
                  ↓       ↑   ↓       ↑
feature/1 →       * ─────┘    │       │
feature/2 →                    * ─────┘

Avantages

• Simple : Une seule branche principale
• Rapide : Déploiement continu, plusieurs fois par jour
• Peu de conflits : Intégration fréquente évite les gros conflits
• Feedback rapide : Les features arrivent vite aux utilisateurs
• Agilité : Adapté aux équipes agiles

Inconvénients

• Nécessite une bonne CI/CD : Tests automatiques obligatoires
• Nécessite de la discipline : Commits petits et fréquents
• Feature toggles : Complexité technique supplémentaire
• Pas adapté aux releases planifiées : Pour du SaaS uniquement

Utilisez TBD si :

• Vous êtes une petite/moyenne équipe (< 10 développeurs)
• Vous faites du déploiement continu (plusieurs fois par jour)
• Vous développez une application web/SaaS
• Vous avez une bonne couverture de tests
• Vous voulez de l'agilité

N'utilisez PAS TBD si :

• Vous avez des cycles de release planifiés
• Vous devez maintenir plusieurs versions
• Vous n'avez pas de tests automatiques
• Vous développez des applications mobiles (review App Store/Play Store)

GitHub Flow: Le meilleur des deux mondes

Beaucoup d'équipes utilisent un hybride entre GitFlow et TBD :

C'est une version simplifiée de GitFlow qui garde le meilleur des deux :

Structure :

• main : Production (comme GitFlow)
• feature/* : Branches de courte durée (comme TBD)

Avantages :

• Plus simple que GitFlow
• Plus structuré que TBD pur
• Compatible avec le déploiement continu
• Facile à comprendre

C'est le workflow que nous utilisons dans le cours CI/CD !

Comparaison des workflows

Lequel choisir ?