infra / git-github

Workflows d'équipe : Git Flow, trunk-based, revue de PR

Leçon 151 exercice

Explication

Ce que vous allez apprendre

Distinguer Git Flow (branches longues, releases planifiées) du trunk-based development
Comprendre le rôle des feature flags pour merger du code inachevé sans l'activer
Identifier ce qu'une Pull Request apporte au-delà d'une simple formalité technique
Utiliser un template de PR standardisé pour faciliter la revue de code
Créer, vérifier et fusionner une Pull Request sans quitter le terminal avec gh

Dans quel contexte ?

L'équipe de boutique-api grandit et passe de deux à huit développeurs. Les branches restent ouvertes de plus en plus longtemps, générant des conflits de plus en plus difficiles à résoudre. L'équipe doit choisir consciemment un mode de collaboration — Git Flow structuré ou trunk-based plus rapide — plutôt que de laisser chacun travailler à sa façon, ce qui devient ingérable à cette taille.

Une question différente : l'organisation collective

D'abord, tout ce qui a été vu jusqu'ici, branches, merge, rebase, conflits, sont des outils individuels. Cette leçon aborde une question différente : comment une équipe entière s'organise-t-elle collectivement autour de ces outils ?

Pas une seule bonne réponse

Il n'existe pas une seule bonne réponse : le choix dépend de la taille de l'équipe, du rythme de livraison souhaité, et de la maturité des pratiques de test automatisé.

Une première philosophie : des branches longues et formelles

Git Flow repose sur des branches longues et bien séparées par rôle : develop pour l'intégration continue, release/* pour préparer une sortie, hotfix/* pour les urgences en production.

Ce que ça apporte, et ce que ça coûte

C'est rassurant pour des équipes qui livrent selon un calendrier planifié, mais cela ajoute de la cérémonie et peut ralentir le rythme.

Une philosophie opposée : tout intégrer très vite

À l'opposé, le trunk-based development mise sur une seule branche longue, main, toujours censée être déployable, et des branches de fonctionnalité extrêmement courtes, fusionnées en quelques heures ou jours au maximum.

Ce que ce style demande en contrepartie

Ce style demande une discipline de tests solide et l'usage de feature flags : un mécanisme qui permet de fusionner du code inachevé dans main sans l'activer pour de vrais utilisateurs, en le cachant derrière un interrupteur de configuration.

Workflow	Durée de vie des branches	Adapté à
Git Flow	Longue (`develop`, `release/*`)	Releases planifiées, équipes nombreuses
Trunk-based	Courte (quelques heures/jours)	Livraison continue, forte couverture de tests

Prérequis

Cette leçon suppose une bonne maîtrise des branches et du merge (leçons précédentes) : un workflow d'équipe n'est qu'une convention appliquée collectivement à ces mêmes outils.

La Pull Request, un lieu de dialogue

Une fois le workflow choisi, il reste un point commun essentiel : la Pull Request n'est pas qu'une formalité technique, c'est le moment où le code est relu par quelqu'un d'autre avant d'entrer dans la base commune.

Ce que cette relecture apporte

Elle détecte des erreurs, partage la connaissance du code dans l'équipe, et maintient une cohérence de style. Un template de PR standardisé aide chaque contributeur à fournir le contexte nécessaire à une bonne revue.

Piège fréquent

Adopter le trunk-based development sans une suite de tests automatisés solide revient à fusionner du code potentiellement cassé directement sur main, censée pourtant rester toujours déployable. Vérifie que la couverture de tests est suffisante avant d'abandonner des branches de fonctionnalité plus longues et plus prudentes.

Automatiser le cycle de revue

Enfin, des outils comme gh (GitHub CLI) permettent de créer, vérifier et fusionner des Pull Requests sans quitter le terminal, intégrant naturellement ce processus dans le flux de travail quotidien.

La leçon suivante s'attaque à un sujet différent, tout aussi important au quotidien : décider ce que Git ne doit jamais suivre, avec .gitignore et .gitattributes.

Commandes & code

Workflows d'équipe

# Git Flow : branches longues, adapté aux releases planifiées
main         -----------------o-------------o---->   (production, tags v1.0, v1.1)
release/1.1  ------------o----/
develop      --o---o---o-----o---o---o---o------>    (intégration continue des features)
feature/x       \-o-o-/
hotfix/1.0.1 -----------o--/  (part de main, merge dans main ET develop)

# Git Flow avec l'extension git-flow (ou manuellement)
git flow init
git flow feature start user-auth       # crée feature/user-auth depuis develop
git flow feature finish user-auth       # merge dans develop, supprime la branche

git flow release start 1.1.0            # crée release/1.1.0 depuis develop
git flow release finish 1.1.0            # merge dans main ET develop, crée le tag v1.1.0

# Trunk-based development : une seule branche longue (main), petites branches très courtes
main  --o--o--o--o--o--o--o--o--o--o--o-->   (toujours déployable)
          \-o-/  \o-/  \-o-o-/  \o-/          (feature branches de quelques heures/jours max)
# Nécessite : feature flags pour cacher le code incomplet déployé sur main

# Feature flag simple (config), pour merger du code inachevé sans l'activer en prod
features:
  new_checkout_flow: false     # activé progressivement, indépendamment du déploiement
  beta_dashboard: true

<!-- Template de Pull Request GitHub : .github/pull_request_template.md -->
## Description
Résume le changement et son contexte.

## Type de changement
- [ ] Bug fix
- [ ] Nouvelle fonctionnalité
- [ ] Breaking change

## Checklist
- [ ] Tests ajoutés/mis à jour
- [ ] Documentation mise à jour
- [ ] Pas de warning de lint

# Créer et suivre une Pull Request via gh CLI
gh pr create --title "feat(auth): add password reset flow" --body "Closes #128" --base main
gh pr checks                        # statut des vérifications CI sur la PR courante
gh pr review --approve -b "LGTM, bon travail"
gh pr merge --squash --delete-branch

Résumé

Git Flow : branches longues (develop, release/*, hotfix/*), adapté aux releases planifiées.
Trunk-based : branches très courtes fusionnées vite dans main, combiné à des feature flags.
Un template de PR standardise la revue (description, checklist, type de changement).
gh pr create/review/merge couvre tout le cycle de revue sans quitter le terminal.

Exercices pratiques

1 disponible

Mission : choisir un workflow pour une équipe qui grandit

Objectif : Diagnostiquer les symptômes d'un mauvais choix de workflow et automatiser le cycle de revue de Pull Request.

Contexte

L'équipe de boutique-api passe de deux à huit développeurs. Les branches de fonctionnalité restent ouvertes plusieurs semaines avant d'être fusionnées, générant des conflits de plus en plus difficiles à résoudre à chaque merge dans main.

Résoudre l’exercice →