Workflows Git¶

Choisir un workflow adapté a votre équipe — trunk-based, GitFlow ou GitHub Flow.

Pourquoi un workflow¶

Sans convention partagee, chaque développeur branche, merge et deploie a sa façon. Le résultat : des conflits permanents, un historique illisible et des déploiements imprévisibles.

Un workflow Git définit :

• quand créer une branche
• depuis quoi brancher
• comment reintegrer le code
• qui valide avant le merge

Trunk-Based Development¶

Tout le monde travaille sur une seule branche (main ou trunk). Les développeurs poussent de petits changements directement ou via des branches a très courte durée de vie (< 1 jour).

gitGraph
    commit id: "feat A"
    branch short-lived
    commit id: "feat B part 1"
    commit id: "feat B part 2"
    checkout main
    merge short-lived id: "merge feat B"
    commit id: "feat C"
    commit id: "fix D"

Quand l'utiliser¶

Avantages¶

• Intégration continue réelle — pas de branches qui divergent pendant des semaines
• Conflits de merge rares et petits
• Historique lineaire et lisible

Risques¶

• Nécessité une CI solide — un push casse bloque tout le monde
• Les features longues demandent des feature flags (voir Feature flags)

GitFlow¶

Modèle formalise par Vincent Driessen en 2010. Deux branches permanentes (main et develop) et trois types de branches temporaires (feature/*, release/*, hotfix/*).

gitGraph
    commit id: "v1.0" tag: "v1.0"
    branch develop
    commit id: "dev 1"
    branch feature/auth
    commit id: "auth 1"
    commit id: "auth 2"
    checkout develop
    merge feature/auth id: "merge auth"
    branch release/1.1
    commit id: "bump version"
    checkout main
    merge release/1.1 id: "v1.1" tag: "v1.1"
    checkout develop
    merge release/1.1 id: "sync develop"

Quand l'utiliser¶

Avantages¶

• Séparation claire entre code en développement et code en production
• Support natif des hotfixes sans perturber le développement
• Historique structure par release

Risques¶

• Complexe — beaucoup de branches a gérer
• Les feature branches longues divergent et génèrent des conflits massifs
• Merge hell sur les grosses releases

GitHub Flow¶

Simplification de GitFlow : une seule branche permanente (main), des feature branches et des pull requests.

gitGraph
    commit id: "init"
    branch feature/login
    commit id: "login 1"
    commit id: "login 2"
    checkout main
    merge feature/login id: "PR #1"
    branch feature/dashboard
    commit id: "dashboard 1"
    checkout main
    merge feature/dashboard id: "PR #2"
    commit id: "hotfix"

Quand l'utiliser¶

Avantages¶

• Simple a comprendre et a enseigner
• Les pull requests centralisent la review et la CI
• Compatible avec la plupart des plateformes (GitHub, GitLab, Gitea)

Risques¶

• Pas de mécanisme natif pour les releases planifiees
• Les feature branches longues posent les mêmes problèmes qu'avec GitFlow

GitLab Flow¶

Variante de GitHub Flow avec des branches d'environnement (staging, production) pour gérer la promotion du code.

graph LR
    FB["feature branch"] -->|"MR"| M["main"]
    M -->|"merge"| S["staging"]
    S -->|"merge"| P["production"]

Quand l'utiliser¶

Quand vous avez besoin de la simplicité de GitHub Flow mais avec un contrôle explicite sur les environnements de déploiement.

Comparatif¶

Outils¶