Atelier GIT2 – une fiche, une PR, une review, un conflit

Nous allons faire à dix-sept ce que fait une équipe de développement tous les jours : chacun contribue un petit fichier à un dépôt commun, en passant par une branche, une pull request et la review d'un camarade. Le dépôt de classe est https://github.com/raphaelpra/git-atelier-2026 ; chacun y ajoute une fiche « une commande git en 10 lignes ». Le conflit que vous rencontrerez à l'étape 8 est provoqué sciemment : tout le monde ajoute sa ligne au même endroit de SOMMAIRE.md.

Comptez 55 minutes pour les étapes 1 à 8 et 10 ; l'étape 9 (une 2e fiche dans un worktree) est pour ceux qui ont fini. Les commandes supposent git ≥ 2.40 (git --version). Dans ce qui suit, <vous> est votre identifiant GitHub et <commande> la commande git dont vous rédigez la fiche (par ex. stash, cherry-pick, reflog).

Deux dépôts distants vont cohabiter, retenez bien leurs noms :

nom	c'est…	vous y poussez ?
origin	votre fork, github.com/<vous>/git-atelier-2026	oui
upstream	le dépôt de classe, github.com/raphaelpra/git-atelier-2026	non : vous n'en avez pas le droit, on y entre par PR

0. Avant de commencer

• Votre binôme de review : votre voisin de droite (le dernier de la rangée relit le premier).

Vérifiez : sur la page du dépôt de classe, vous voyez le bouton Fork en haut à droite, et main porte un petit cadenas dans l'onglet Branches.

1. Fork et clone

1. Sur GitHub, bouton Fork → Create fork (laissez les options par défaut). Vous avez maintenant github.com/<vous>/git-atelier-2026.
2. Clonez votre fork, puis déclarez le dépôt de classe comme upstream :

git clone git@github.com:<vous>/git-atelier-2026.git
cd git-atelier-2026
git remote add upstream https://github.com/raphaelpra/git-atelier-2026.git
git fetch upstream

Pas de clé SSH ? Clonez par https://github.com/<vous>/git-atelier-2026.git : au premier push, git ouvre une fenêtre de connexion GitHub. (Avec gh, cf. annexe : gh repo fork raphaelpra/git-atelier-2026 --clone fait tout cela d'un coup.)

Vérifiez : git remote -v affiche quatre lignes (origin fetch/push, upstream fetch/push) ; git branch -r montre origin/main et upstream/main.

2. Choisir une commande, créer sa branche

1. Ouvrez README.md : la liste des commandes à documenter. Prenez de préférence une commande vue aujourd'hui ou en GIT1. Premier arrivé, premier servi : la branche poussée fait foi, regardez les branches déjà présentes sur les forks des autres (ou demandez à voix haute).
2. Créez votre branche depuis main :

git switch main
git switch -c fiche/<commande>

Vérifiez : git status commence par On branch fiche/<commande> ; git log --oneline -1 montre « Merge pull request #1 from raphaelpra/fiche/show », la fiche d'exemple.

3. Rédiger la fiche

1. Copiez le modèle et remplissez-le (dix lignes, pas un roman) :

cp fiches/_modele.md fiches/<commande>.md

2. Le modèle demande : à quoi sert la commande, la forme la plus courante, un exemple qu'on peut taper, un piège, une commande voisine. Testez votre exemple dans git-carnet avant de l'écrire.
3. Un exemple complet : fiches/show.md, arrivée par la PR n° 1. Lisez la fiche, puis la PR (onglets Commits et Files changed) : la vôtre aura la même forme.
4. Commitez la fiche seule :

git add fiches/<commande>.md
git commit -m "Ajoute la fiche <commande>"

Vérifiez : git show --stat HEAD liste un seul fichier, le vôtre. Le message est à l'impératif et tient sur une ligne.

4. Modifier SOMMAIRE.md (la liste partagée)

SOMMAIRE.md contient la liste des fiches, vide au départ. Tout le monde va ajouter sa ligne au même endroit, à la fin : c'est ce qui provoquera le conflit de l'étape 8.

1. Ajoutez votre fiche à la fin de la liste :

- [`<commande>`](fiches/<commande>.md) – une ligne de résumé

2. Commit séparé (un sujet, un commit) :

git add SOMMAIRE.md
git commit -m "Référence la fiche <commande> dans le sommaire"

Vérifiez : git log --oneline montre vos deux commits au-dessus de « Merge pull request #1 » ; git diff main --stat liste deux fichiers.

5. Pousser sur votre fork

git push -u origin fiche/<commande>

Vérifiez : la commande se termine par branch 'fiche/<commande>' set up to track 'origin/fiche/<commande>' ; git status dit Your branch is up to date with 'origin/fiche/<commande>'. Sur GitHub, votre fork affiche un bandeau jaune « Compare & pull request ».

6. Ouvrir la pull request

1. Bandeau jaune → Compare & pull request. Vérifiez la ligne du haut : base raphaelpra/git-atelier-2026 : main ← head <vous>/git-atelier-2026 : fiche/<commande>.
2. Titre : « Fiche ». Le corps est prérempli par le modèle du dépôt : cochez les cases, ajoutez une phrase.
3. Dans le corps, mentionnez votre relecteur, votre voisin de droite : Relecteur : @<son-identifiant> (il reçoit une notification). La colonne Reviewers est réservée aux collaborateurs du dépôt, ce que vous n'êtes pas. Puis Create pull request.

Vérifiez : la PR apparaît dans l'onglet Pull requests du dépôt de classe avec 2 commits et 2 files changed. En bas, GitHub dit soit « This branch has no conflicts » (vous êtes parmi les premiers), soit « This branch has conflicts that must be resolved » : dans ce cas, passez d'abord par l'étape 7 (la review de votre voisin n'attend pas), puis l'étape 8.

7. Relire la PR de votre voisin

Ouvrez la PR de votre voisin de gauche (c'est vous son reviewer), onglet Files changed.

1. Survolez une ligne de sa fiche, cliquez le + bleu : laissez un commentaire précis (une coquille, un exemple qui ne tourne pas, une ligne à ajouter). Puis Start a review.
2. En haut à droite, Finish your review : Approve si la fiche vous convient, Request changes avec une phrase qui dit ce que vous attendez sinon.
3. Si vous avez demandé un changement : l'auteur corrige (étape 7 bis ci-dessous) ; quand il vous a répondu, retournez sur la PR, vérifiez, puis Approve.

7 bis, côté auteur : quand une review vous demande un changement, corrigez sur la même branche, commitez, git push (pas besoin de -u cette fois). Le commit s'ajoute à la PR tout seul. Répondez au commentaire (« corrigé dans abc123 ») et cliquez Resolve conversation.

Vérifiez : dans l'onglet Conversation de la PR de votre voisin, votre review apparaît avec la mention approved these changes ; la vôtre affiche celle de votre relecteur.

8. Le conflit : fetch upstream, merge upstream/main

Dès que la première PR est mergée (je le fais moi-même et je l'annonce), toutes les autres sont en conflit sur SOMMAIRE.md : main et votre branche ont chacune ajouté une ligne au même endroit. On ne résout pas ça dans l'interface GitHub : on fait entrer le nouveau main dans sa branche, en local.

git fetch upstream
git merge upstream/main

Git s'arrête sur SOMMAIRE.md :

CONFLICT (content): Merge conflict in SOMMAIRE.md

1. Ouvrez SOMMAIRE.md. Entre <<<<<<< et =======, votre version ; entre ======= et >>>>>>>, celle de main (les fiches déjà mergées). La bonne résolution n'est ni l'une ni l'autre : toutes les lignes, celles de main puis la vôtre.
2. Supprimez les marqueurs, enregistrez, puis terminez le merge :

git add SOMMAIRE.md
git commit
git push

Le message « Merge remote-tracking branch 'upstream/main' » est prérempli : gardez-le. Le push met la PR à jour toute seule.

Si vous vous perdez : git merge --abort remet tout comme avant, et vous recommencez.

Vérifiez : git log --oneline --graph -5 montre votre commit de merge, avec deux parents ; git status dit up to date with 'origin/fiche/<commande>' ; sur GitHub, la PR affiche « This branch has no conflicts ». Il se peut que quelqu'un d'autre soit mergé entre-temps et que le conflit revienne : recommencez l'étape, ça va vite la deuxième fois.

9. S'il vous reste du temps : une 2e fiche dans un worktree

Votre PR attend son approbation, ou elle est déjà mergée. Plutôt que de rester les bras croisés ou de bricoler sur la même branche, ouvrez un second dossier de travail sur une nouvelle branche, à partir de upstream/main (pas de votre 1re branche, sinon la 2e PR embarquerait la 1re fiche) :

git fetch upstream
git worktree add ../git-atelier-fiche2 -b fiche/<autre-commande> upstream/main
cd ../git-atelier-fiche2

Refaites les étapes 3 à 6 dans ce dossier : fiche depuis le modèle, SOMMAIRE.md (une ligne à la fin de la liste), deux commits, git push -u origin fiche/<autre-commande>, PR. Si une review arrive sur la 1re PR pendant ce temps, retournez simplement dans le 1er dossier (cd ../git-atelier-2026) : rien à mettre de côté.

Vérifiez : git worktree list affiche deux lignes, chacune avec sa branche ; dans le 1er dossier, git branch montre les deux branches, et git switch fiche/<autre-commande> est refusé (« already checked out »).

10. Le merge

Vous n'avez pas le droit d'écrire dans le dépôt de classe : c'est moi qui merge, comme le mainteneur d'un projet libre. Je merge les PR approuvées par leur relecteur et sans conflit, au fil de l'eau. Si la vôtre est approuvée mais en conflit, repassez par l'étape 8 ; si elle attend, levez la main. Une fois mergée, votre branche existe encore sur le fork et en local.

Une fois votre PR mergée, mettez votre main à jour, sur le fork aussi :

cd ../git-atelier-2026
git switch main
git pull upstream main
git push origin main

Vérifiez : git log --oneline -3 main montre le commit de merge de votre PR ; SOMMAIRE.md sur main liste votre fiche ; sur GitHub, votre fork dit « This branch is up to date with raphaelpra:main ».

11. Nettoyer

Une PR mergée, c'est une branche et un worktree qui ne servent plus :

git worktree remove ../git-atelier-fiche2     # après le merge de la 2e PR ; sinon plus tard
git branch -d fiche/<commande>                # -d refuse si la branche n'est pas mergée : bon signe
git fetch --prune origin
git worktree list
git branch -a

Vérifiez : git worktree list n'a plus qu'une ligne ; git branch -a ne montre plus que main, origin/main, upstream/main (et la branche de la 2e fiche si sa PR est encore ouverte).

Ce que vous devez avoir à la fin

• Un fork <vous>/git-atelier-2026 dont main est à jour avec le dépôt de classe.
• Au moins une fiche fiches/<commande>.md mergée dans raphaelpra/git-atelier-2026 par une PR approuvée par un camarade, sans conflit résiduel dans SOMMAIRE.md.
• Une review écrite par vous sur la PR d'un camarade : au moins un commentaire sur une ligne, puis une approbation.
• Un conflit résolu à la main (merge upstream/main, SOMMAIRE.md corrigé, push).
• Si vous avez eu le temps : un worktree créé, utilisé pour une 2e branche, puis supprimé, et une 2e PR.
• Un dépôt local propre : git status vide, git worktree list sur une ligne, plus de branche fiche/… mergée.

Rien à rendre : le dépôt de classe garde la trace de tout. Pour toute question, vous pouvez me contacter par email : raphael@imagine-app.fr