Workflows distribués Git

Git est distribué : chaque développeur possède une copie complète du dépôt. Cette architecture permet plusieurs modèles de collaboration. Ce guide présente les trois principaux workflows distribués et vous aide à choisir celui qui correspond à votre équipe ou projet.

Prérequis : Remotes fondamentaux et Merge et conflits.

Ce que vous allez apprendre

Comprendre les 3 workflows distribués : centralisé, integration-manager, dictateur
Identifier le workflow adapté à votre taille d’équipe et votre projet
Contribuer à un projet open source avec le workflow fork + PR
Gérer les remotes multiples (origin, upstream) dans un contexte de fork

1. Workflow centralisé

Le modèle le plus simple : un seul dépôt partagé, tout le monde pousse sur les mêmes branches.

        Dépôt central (origin)
         ┌──────────┐
         │   main   │
         └────┬─────┘
        ┌─────┼─────┐
        ▼     ▼     ▼
     Dev A  Dev B  Dev C

Fonctionnement

Tous les développeurs clonent le même dépôt et poussent directement sur main (ou develop) :

git clone https://gitlab.com/team/project.git
# ... travailler ...
git pull --rebase origin main
git push origin main

Si un collègue a poussé entre-temps, Git rejette le push. Il faut d’abord intégrer ses changements (pull --rebase ou pull), puis repousser.

Quand l’utiliser

Petites équipes (2-5 personnes)
Projets internes simples
Équipes habituées à SVN qui migrent vers Git

Limites

Pas de revue de code formelle avant l’intégration
Conflits fréquents si l’équipe grandit
Un commit cassé sur main impacte tout le monde

2. Workflow Integration-Manager (fork)

C’est le modèle standard de l’open source (GitHub, GitLab). Un mainteneur contrôle le dépôt principal. Les contributeurs passent par un fork et des pull/merge requests.

     Dépôt principal (blessed)
         ┌──────────┐
         │ mainteneur│
         └────┬─────┘
              │ merge PR
         ┌────┴─────┐
         ▼          ▼
     Fork Dev A   Fork Dev B
     (origin)     (origin)

Fonctionnement

Le contributeur forke le dépôt principal

Il clone son fork et ajoute le dépôt principal comme upstream :

git clone https://github.com/moi/project.git
git remote add upstream https://github.com/original/project.git

Il crée une branche feature, travaille, pousse sur son fork :

git switch -c fix/typo-readme
# ... modifications ...
git push -u origin fix/typo-readme

Il ouvre une pull request vers le dépôt principal
Le mainteneur review, demande des changements si nécessaire, puis merge

Le contributeur synchronise son fork :

git fetch upstream
git switch main
git merge upstream/main
git push origin main

Quand l’utiliser

Projets open source
Équipes où la revue de code est obligatoire
Quand les contributeurs n’ont pas les droits d’écriture sur le dépôt principal

Avantages

Le mainteneur contrôle ce qui entre dans le projet
Chaque contribution est revue avant intégration
Les contributeurs travaillent de manière indépendante

3. Workflow Dictator & Lieutenants

Utilisé par les très grands projets (le noyau Linux). Un dictateur bienveillant intègre le travail de lieutenants, qui eux-mêmes intègrent les contributions des développeurs.

         Blessed repo
         ┌────────────┐
         │  Dictateur  │
         └──┬─────┬───┘
            │     │
     ┌──────┘     └──────┐
     ▼                   ▼
  Lieutenant A       Lieutenant B
  (sous-système)     (sous-système)
     ▲     ▲           ▲     ▲
     │     │           │     │
  Dev 1  Dev 2      Dev 3  Dev 4

Fonctionnement

Les développeurs soumettent leur travail au lieutenant de leur sous-système
Le lieutenant intègre, teste, puis soumet au dictateur
Le dictateur intègre dans le dépôt de référence (blessed repo)
Tout le monde synchronise depuis le blessed repo

Quand l’utiliser

Projets très larges (centaines de contributeurs)
Noyau Linux, certains projets GNU

Ce workflow est rarement pertinent pour les projets courants. Il est présenté ici pour compréhension.

Comparatif

Critère	Centralisé	Integration-Manager	Dictator
Taille d’équipe	2-5	5-100+	100+
Revue de code	Optionnelle	Obligatoire (PR)	Multi-niveaux
Complexité	Faible	Moyenne	Élevée
Contrôle	Partagé	Mainteneur	Hiérarchique
Cas d’usage	Projets internes	Open source, équipes	Noyau Linux

Contribuer à un projet : les bonnes pratiques

Quel que soit le workflow, ces règles facilitent l’intégration de vos contributions :

Un sujet par branche : ne mélangez pas un bugfix et une feature dans la même PR
Commits atomiques : chaque commit fait une chose et la fait bien
Rebasez avant de soumettre : git rebase upstream/main pour éviter les conflits au mainteneur
Messages clairs : décrivez le « quoi » et le « pourquoi »
Testez : assurez-vous que votre code fonctionne avant de soumettre
Respectez les conventions du projet (linting, format des commits, etc.)

Dépannage : problèmes courants

Symptôme	Cause probable	Solution
Push rejeté sur le dépôt original	Pas les droits d’écriture	Poussez sur votre fork, puis ouvrez une PR
Fork désynchronisé	Pas de fetch upstream	`git fetch upstream && git merge upstream/main`
PR avec conflits	Branche pas à jour	`git rebase upstream/main` puis force-push sur votre fork
Trop de commits dans la PR	Historique brouillon	`git rebase -i` pour squasher avant soumission

À retenir

Centralisé : simple, tout le monde pousse sur le même dépôt (petites équipes)
Integration-Manager : fork + PR + revue, le standard de l’open source
Dictator & Lieutenants : hiérarchique, pour les très grands projets
Bonnes pratiques : une branche par sujet, commits atomiques, rebase avant soumission
La plupart des équipes utilisent le workflow Integration-Manager avec des merge requests

Prochaines étapes

Pull requests et code review Le workflow PR en détail : créer, reviewer, merger.

Workflows Git Gitflow, Feature Branch, Trunk-Based : les stratégies de branching.

Maintenir un projet Accepter les contributions et préparer des releases.