Workflows Git — aperçu et comparatif

Université de Toulon

LIS UMR CNRS 7020

2026-10-16

Pourquoi des workflows ?

Un workflow Git formalise comment une équipe collabore sur le code : modèle de branches, règles de fusion, revues et cadence des releases. Il rend le processus prévisible, sécurisé et automatisable.

Objectifs essentiels :

Clarté — conventions de branches et de commits pour savoir qui fait quoi.
Collaboration — revues obligatoires, petites PRs, responsabilités partagées.
Qualité — gates CI (tests, lint, scans) avant toute fusion.
Livraison — stratégie de release et règles de déploiement.

Important

Choisissez un workflow adapté à votre équipe, formalisez-le, automatisez-le via CI et appliquez‑le strictement.

Vocabulaire clé

Workflow : ensemble de pratiques et règles pour utiliser Git (process, roles, conventions).
Pull request (PR) / Merge request (MR) : demande de fusion d’une branche — inclut review, CI et discussion.
CI (Intégration continue / Continuous Integration) : pipelines automatiques (tests, lint, build) déclenchés par les pushes/PRs.
CD (Livraison continue / Continuous Delivery) : automatisation des déploiements après CI réussie.
Branch protection : règles côté serveur (ex. pas de push direct, exigences de review/CI) pour protéger main.
Conventional Commits : convention pour formater les messages de commit (ex. feat:, fix:) — utile pour changelogs automatisés.
Rebase vs Merge : rebase = historique linéaire (réécriture locale), merge = commit de fusion (trace explicite).

Workflow centralisé (style SVN)

Principe

une branche principale (main/master) et tout le monde push/pull dessus.

Developers -> commit -> push -> origin/main

Commandes typiques :

# basculer sur la branche principale (moderne)
git switch main
# synchroniser en conservant un historique linéaire local
git pull --rebase
git add .
git commit -m "..."
git push origin main

Avantages : simple, facile à comprendre pour débutants.
Inconvénients : risque élevé de conflits, intégrité limitée, pas de revue obligatoire.

Feature branch workflow (branche par fonctionnalité)

Principe

Chaque fonctionnalité ou bugfix a sa propre branche feature/x.
Fusion via merge ou PR dans main.

main ---o-----o---------o
        \         /
 feature1 o-----o

Commandes :

# créer et basculer (moderne)
git switch -c feature/ma-fonctionnalite
# pousser et définir la branche distante par défaut
git push --set-upstream origin feature/ma-fonctionnalite
# pendant le travail: garder votre branche à jour avec `main`
git fetch origin
git rebase origin/main
# après review et tests (ou via PR) :
git switch main
git merge --no-ff feature/ma-fonctionnalite   # ou utilisez squash via l'interface PR
git push origin main

Avantages : isole le travail, facilite revue et CI.
Inconvénients : branches longues peuvent diverger; nécessité de synchroniser (rebase/merge).

Gitflow (Vincent Driessen)

Principe

Branches principales : main (release) et develop (intégration)
Branches support : feature/, release/, hotfix/

main ----o----------o
         \        /
 develop ---o--o--o
           /     \
 feature1       release

Commandes (exemple simplifié) :

# feature
git switch develop
git switch -c feature/x
# push feature
git push -u origin feature/x
# finish feature
git switch develop
git merge --no-ff feature/x
# release
git switch -c release/1.2 develop
git switch main
git merge --no-ff release/1.2
git tag -a v1.2

Avantages : clair pour projets avec versions/stabilisation. Conserve historique de releases.
Inconvénients : plus complexe, lourdeur pour déploiements rapides.
Vincent Driessen Gitflow — http://nvie.com/posts/a-successful-git-branching-model/
https://www.atlassian.com/fr/git/tutorials/comparing-workflows/gitflow-workflow

GitHub Flow (simplifié, PR-based)

Principe

Branche courte depuis main, ouvrir Pull Request, revue, merge, déploiement continu.
Pas de develop ni branche de release.

main ---o---o---o
         \   /
         PR-merge

Bon pour équipes produisant déploiements fréquents (CI/CD). Favorise petites PRs.
GitHub Flow — https://guides.github.com/introduction/flow/

Forking workflow (open-source)

Principe

Chaque contributeur fork le repo principal, travaille dans son fork, ouvre Pull Request vers le repo parent.

Upstream (org/repo)
   ^
   |  Pull Request
Fork (user/repo) <- clone

# clone du fork
git clone git@github.com:utilisateur/repo.git
git remote add upstream git@github.com:org/repo.git
# synchroniser (fetch + rebase upstream pour éviter les merges locaux)
git fetch upstream
git switch main
git rebase upstream/main
# pousser la branche mise à jour sur votre fork si besoin
git push origin main

Avantages : sécurité (pas d’accès direct), isolation des contributeurs, récupération facile des contributions et des mises à jour de l’origine.
Inconvénients : overhead pour synchroniser forks.

Trunk-based development (TBD)

Principe

Tout le monde intègre fréquemment (plusieurs fois par jour) sur main (ou trunk), via petites branches très courtes.
Pre-integration via CI : tests automatisés avant merge.
Favorise feature flags, CI rapide, releases continues.

Avantages : réduit divergence, facilite CI/CD.
Inconvénients : nécessite tests TRES solides, discipline et feature flags.
Trunk-based development — https://trunkbaseddevelopment.com/

Comparatif rapide

Centralisé : très simple, pas recommandé pour équipes collaboratives.
Feature branch : bon compromis pour la plupart des équipes.
GitHub Flow : léger, idéal pour déploiements continus.
Gitflow : adapté aux équipes avec releases planifiées.
Forking : idéal pour contributions open-source.
Trunk-based : requis pour livraison continue à grande échelle.

Intégration CI/CD

CI: Intégration Continue
- Chaque push sur une branche active déclenche pipelines (tests, lint, builds).
- PRs doivent passer la pipeline avant merge.
- Protect branch rules : exiger revue, tests verts, pas de push direct (par ex. sur main).
- Test early, fail fast, fix quickly.
CD : Livraison Continue
- Déploiement automatisé en production après CI réussie.

CLI GitHub

GitHub CLI (gh) facilite la gestion des repositories, PRs, issues, releases depuis terminal, …

# cloner un repo GitHub
gh repo clone utilisateur/repo
# Créer un nouveau repo GitHub
gh repo create mon-nouveau-repo --private 
# créer une PR via GitHub CLI
gh pr create --fill --base main --head feature/x
# récupérer et basculer sur la branche d'une PR
gh pr checkout 123

Conclusion

Tous les projets (même seul) bénéficient d’un workflow clair.
- Choisissez un workflow adapté à votre équipe et formalisez-le dans le README du projet.
- Configurez règles de branche et CI pour l’automatisation.
  - Pour commencer, protégez main contre les pushes directs et exigez des revues de code via PRs.
  - Automatisez les tests (quelle que soit la commande de votre outillage : make test, mvn verify, pytest, etc.) via CI pour chaque PR et à chaque merge sur main.

Exercice final : fusionner à deux, en provoquant (puis en résolvant) un conflit

Dans le dépôt distant que l’enseignement fournit — vous deux y avez un accès en écriture — et indépendamment de son contenu :

Le fichier partagé contributions/README.md doit exister sur main avec une ligne Dernière mise à jour : …. Si le dépôt fourni ne le contient pas, l’un des deux l’y ajoute directement et le pousse ; l’autre fait git pull.
Chaque membre du binôme crée sa propre branche depuis main (git switch -c <pseudo>-contrib).
Chacun ajoute un fichier individuel contributions/<pseudo>.md décrivant une chose apprise du guide Git ; puis chacun modifie de son côté la ligne Dernière mise à jour : … de contributions/README.md pour y mettre son pseudo. On committe, on pousse, on ouvre une pull request.
Chaque PR est relue par l’autre membre du binôme avant tout merge : un commentaire, une demande, une approbation.
Fusionnez la première PR, puis tentez la seconde : le conflit apparaît. Reproduisez-le en local, depuis votre branche : git pull origin main — les marqueurs de conflit apparaissent alors dans votre copie de travail.
Résolution en duo, en personne : identifier qui édite, comprendre les trois régions du fichier en conflit, git add pour marquer la résolution, commit de merge.
Vous avez modifié un fichier sans committer avant de changer de branche ? git restore <fichier> annule la modification, git switch <votre-branche> vous remet en place — pas de checkout (gh pr checkout, lui, est un verbe du CLI GitHub, sans rapport avec git checkout).

Ce que ce exercice ancre :

Le cycle complet branche → PR → relecture → merge du § GitHub Flow.
Qu’un conflit est un événement normal et local, jamais une erreur à craindre (rappel : section « Identifier et Résoudre des Conflits » du guide Bases).
La grammaire moderne des commandes : switch/restore là où l’ancien checkout faisait tout.