Un commit : des modifications, et un état

• on commite des modifications : celles que l'on a placées dans l'index ;
• en retour, le commit reçoit un hash (a9bfd1f…) qui désigne un état complet du projet, un seul, et qui ne changera plus ;
• revenir à n'importe quel commit est donc instantané : on retrouve le projet entier tel qu'il était ;
• même hash chez deux personnes = exactement le même projet, au fichier près.

L'historique est un graphe

• chaque commit connaît son parent ; mis bout à bout, les commits forment une chaîne ;
• la chaîne peut se séparer (une branche) puis se rejoindre (un merge, commit à deux parents) ;
• git log --oneline --graph --all la dessine dans le terminal ; git show <hash> montre un commit et son diff ; HEAD~1 désigne le parent de HEAD.

L'index : le brouillon du prochain commit

• git add f copie l'état actuel de f dans l'index ; git commit enregistre l'index, pas vos fichiers ;
• une modification faite après le add n'est donc pas dans le commit, tant qu'on ne refait pas add ;
• l'intérêt : ne commiter qu'une partie de ce que l'on a modifié (un fichier sur trois, voire quelques lignes avec git add -p) ;
• git restore --staged f retire f de l'index, sans toucher au fichier.

Juste après un git add, git diff n'affiche rien : working tree et index sont égaux. C'est git diff --staged qui montre ce que le commit contiendra.

Le trio : working tree, index, HEAD

Presque toutes les commandes de GIT1 déplacent des choses entre ces trois cases. Quand une commande vous surprend, demandez-vous laquelle elle vient de toucher.

.gitignore : ce qu'on ne versionne pas

__pycache__/
.venv/
.env
*.png
!logo.png

• un fichier texte à la racine, commité, un motif par ligne ; les fichiers ignorés disparaissent de git status ;
• on n'y met ni ce qui se régénère (caches, environnements, sorties de calcul) ni ce qui est secret (clés, mots de passe) ;
• on part d'un modèle (celui de l'outil, ou ceux de GitHub) plutôt que de l'écrire de tête.

Un .env déjà commité ne disparaît pas en l'ajoutant au .gitignore : il reste suivi (git rm --cached .env), et surtout il reste dans l'historique. Une clé publiée est une clé à changer.

Pas une copie : un pointeur

                         ┌─ garniture
                         ▼
a7d3639 ← 7ac8892 ← 093450a ← a9bfd1f ← 12ed6ff
                                   ▲
                                   └─ main ◀── HEAD

• une branche = 41 octets dans .git/refs/heads/ : le hash d'un commit ; elle avance à chaque commit ;
• HEAD dit sur quelle branche vous êtes ; git switch <b> le déplace, et les fichiers suivent ;
• git switch -c <b> crée et y va ; git branch -d <b> supprime (refuse si non fusionnée) ;
• git switch --detach <hash> : HEAD détachée, pour regarder le passé ; switch -c pour garder ce qu'on y a fait.

Une branche coûte 41 octets : aucune raison de s'en priver, une par idée, par essai, par bug.

Fusionner : deux cas

avant : … ← a9bf (main) ← 12ed (garniture)
après : … ← a9bf ← 12ed (main, garniture)

*   fcd6 Merge branch 'sauce'
|\
| * 1782 Annonce la section sauces
* | 12ed Ajoute les garnitures
|/
* 0934 Ajoute la tarte

Seule la branche courante bouge : git merge sauce depuis main fait avancer main, jamais sauce.

Le conflit : git vous pose une question

Un conflit survient quand les deux branches ont modifié les mêmes lignes depuis leur ancêtre commun. Git ne devine pas : il fusionne tout le reste, et vous laisse trancher ce bloc-là.

<<<<<<< HEAD
Cuisson : 3 min par face, à feu vif.      ← votre branche
=======
Cuisson : 1 min 30 par face.              ← la branche fusionnée
>>>>>>> cuisson

Deux branches qui modifient le même fichier à cent lignes d'écart ne sont pas en conflit : git raisonne par zones de lignes, pas par fichier.

Le conflit : en sortir

1. ouvrir le fichier, choisir ou combiner, supprimer les trois marqueurs ;
2. git add <fichier> : « c'est réglé » ;
3. git commit : le message « Merge branch … » est pré-rempli.

Tant que vous n'avez pas fait git add + git commit, vous restez « en cours de merge » : git status vous le rappelle.

restore : jeter des modifications

$ git restore recettes/crepes.md            ← le fichier redevient celui de l'index
$ git restore --staged recettes/crepes.md   ← annule un add : l'index redevient égal à HEAD

• restore <f> recopie l'index dans le fichier ; restore --staged <f> recopie HEAD dans l'index : ce sont les deux flèches "retour" du trio ;
• git restore <f> est irréversible : ces modifications n'existaient nulle part ailleurs, rien ne les retrouvera.

amend et reset : réécrire ce qui n'est pas partagé

$ git commit --amend             ← refait le dernier commit (message, fichier oublié)
$ git reset --soft HEAD~1        ← « décommite » : tout reste prêt à être recommité
$ git reset HEAD~1               ← défait le commit et le add ; les fichiers restent modifiés
$ git reset --hard HEAD~1        ← tout disparaît, y compris les modifications non commitées ⚠

• reset fait reculer la branche ; le mode dit ce qu'on fait de l'index et du working tree ;
• tout cela réécrit l'historique : permis, tant que personne d'autre n'a ces commits ;
• un commit retiré par reset n'est pas effacé pour autant : l'annexe reflog montre comment le retrouver.

revert : annuler sans réécrire

$ git revert a9bfd1f
[main f65d87e] Revert "Précise la cuisson des crêpes"

• revert ne supprime rien : il ajoute un nouveau commit qui applique le changement inverse ;
• l'historique reste vrai, et vos collègues le reçoivent par un simple pull ;
• reset réécrit le passé, revert ajoute au présent : dès qu'un commit est partagé, c'est revert.

🖐️ Hands-on 1 — cloner le carnet (2 min)

Le dépôt d'exercice de la séance, le carnet de recettes de GIT1, est sur GitHub. Récupérez-le pendant que je vous explique ce qui se passe :

1. ouvrez un terminal (Git Bash sous Windows), placez-vous dans votre dossier de travail : cd ~/mines (ou ce qui vous sert) ;
2. git clone https://github.com/raphaelpra/git-carnet.git ;
3. cd git-carnet, puis ls.

Git est distribué

• le carnet est né sur mon ordi, en GIT1 ; je l'ai poussé sur GitHub ; vous venez de le cloner. Il existe maintenant en trois copies, et chacune contient tout l'historique : git log vous montre mes commits ;
• sans réseau, tout marche chez vous : commiter, créer une branche, fusionner, revenir en arrière ;
• GitHub n'est qu'une copie complète de plus, sur un serveur. Rien, techniquement, ne la distingue des deux autres : c'est l'équipe qui décide qu'elle fait foi. C'est tout le sujet de cette partie.

Un dépôt distant : une autre copie, ailleurs

Un dépôt distant (remote) est une autre copie complète du même dépôt, ailleurs : sur GitHub, sur un serveur, chez un collègue.

Rien n'est synchronisé en continu : les deux copies ne se parlent que lorsque vous tapez fetch, pull ou push. Entre deux, chacune vit sa vie.

Un remote : un surnom pour une URL

Pour ne pas retaper l'URL à chaque fois, git lui donne un surnom. origin est celui que git clone donne au dépôt d'où l'on vient : ce n'est pas un mot-clé, juste une convention.

$ git remote -v
origin  https://github.com/raphaelpra/git-carnet.git (fetch)
origin  https://github.com/raphaelpra/git-carnet.git (push)

• git push origin main se lit donc « envoie main à l'URL surnommée origin » ;
• on peut avoir plusieurs surnoms, vers plusieurs dépôts : nous y viendrons dans cette partie.

🖐️ Hands-on 1 (suite) — explorer le clone (5 min)

Dans git-carnet, cloné tout à l'heure :

1. git remote -v : quel surnom, quelle URL ?
2. git log --oneline --graph --all : repérez HEAD, main, et des étiquettes que nous n'avons pas expliquées : origin/main, origin/sauce… ;
3. git switch -c echauffement, modifiez le README.md, add, commit ;
4. git switch main, git merge echauffement : fast-forward ou merge commit ? pourquoi ?
5. git branch -d echauffement, puis git status : que veut dire Your branch is ahead of 'origin/main' by 1 commit ?

C'est la question de la slide suivante.

Les branches de suivi : origin/main

À la fin du hands-on, chez vous :

• origin/main est une photo de la position de main sur origin, prise lors du dernier clone, fetch, pull ou push ;
• elle est en lecture seule : on ne commite pas dessus, on la compare, on la fusionne ;
• ahead by 1 commit : votre main a un commit que origin/main n'a pas ; rien n'est parti tant que vous n'avez pas fait push.

Pendant ce temps, sur mon ordi

Je fais deux commits dans mon clone du carnet, et je les pousse sur GitHub :

$ git switch main
$ printf '# Galettes\n\n- 250 g de farine de sarrasin\n' > recettes/galettes.md
$ git add recettes/galettes.md && git commit -m "Ajoute les galettes"   ← commit 1
$ sed -i 's/- 30 g de sucre/- 30 g de sucre\n- 1 gousse de vanille/' recettes/tarte.md
$ git commit -am "Ajoute la vanille à la tarte"                         ← commit 2
$ git push
$ git log --oneline --graph main origin/main

Sur GitHub, les deux commits sont là : https://github.com/raphaelpra/git-carnet/commits/main

Et chez vous ?

$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.

Rien n'a bougé : ni vos fichiers, ni votre graphe, ni origin/main. Mes commits sont sur GitHub, mais votre dépôt ne le sait pas encore.

origin/main ne bouge jamais toute seule : il faut aller voir.

La recette de GIT1, enfin expliquée

La dernière étape du TP GIT1 proposait de publier git-homework sur GitHub en suivant une recette. Ligne à ligne :

$ git remote add origin git@github.com:VOUS/git-homework.git   ← donne le surnom origin à cette URL
$ git push -u origin main                                       ← envoie main, crée origin/main, lie les deux
$ git remote -v                                                 ← vérifie

• le dépôt GitHub devait être créé vide, sans README ni .gitignore : sinon GitHub crée un premier commit de son côté, et vos deux histoires n'ont aucun ancêtre commun (push refusé ; l'annexe autres dépôts montre comment les réunir) ;
• -u (upstream) mémorise le lien : git status peut ensuite dire ahead / behind ;
• la seule vraie preuve que tout est parti : un git clone frais, ailleurs.

🖐️ Hands-on 2 — intégrer mes commits (3 min)

Dans git-carnet, votre main et origin/main ont divergé : 1 commit à vous, 2 à moi.

1. git merge origin/main : l'éditeur s'ouvre pour le message du merge, enregistrez, fermez ;
2. git log --oneline --graph main origin/main : dessinez ce que vous voyez ;
3. git status : que veut dire ahead by 2 commits ?

Question : git a créé un commit de plus. Lequel, et pourquoi ?

Démo (1/2) : deux collègues, un seul dépôt

Sur mon ordi, trois dossiers : un dépôt qui joue le rôle de GitHub, et deux clones, comme deux collègues.

Bob commite et pousse le premier :

$ cd bob
$ echo "Bob" >> README.md && git commit -am "Bob signe le README"
$ git push

Contribuer : collaborateur ou fork

Un fork n'est rien d'autre qu'une copie du dépôt, faite par GitHub sur votre compte (bouton Fork), qui garde le lien avec l'original.

Un fork, deux remotes : origin et upstream

$ git clone https://github.com/vous/projet.git                        ← origin = votre fork
$ git remote add upstream https://github.com/original/projet.git      ← upstream = l'original
$ git fetch upstream
$ git log --oneline main..upstream/main      ← ce que l'original a et que votre fork n'a pas
$ git merge upstream/main                    ← l'intégrer, puis git push : votre fork est à jour

upstream n'est qu'un surnom de plus, comme origin : un remote de plus, ses branches de suivi (upstream/main), dans le même .git.

Anatomie d'une pull request

Une pull request (PR) dit : « voici ma branche, voulez-vous l'intégrer dans la vôtre ? »

• base ← head : raphaelpra/…:main ← vous/…:fiche/stash ; on lit cette ligne avant de cliquer ;
• la PR suit la branche : chaque git push sur fiche/stash ajoute ses commits à la PR, sans rien rouvrir ;
• Conversation, Commits, Checks (les tests automatiques), Files changed (le diff, où l'on commente une ligne) ;
• review : Comment, Request changes ou Approve ;
• le bouton Merge : fait le git merge côté GitHub, une fois la PR approuvée.

En clair : la PR est un git merge qu'on a rendu discutable. Elle n'existe pas dans git, seulement sur GitHub.

Une boîte à outils, pas une méthode

Git vous donne des branches, des remotes, merge et rebase. Il ne dit rien de :

• quel dépôt fait foi (git est distribué : aucun clone n'est plus « vrai » qu'un autre) ;
• qui a le droit de pousser sur main, et si quelqu'un relit avant ;
• combien de temps vit une branche, comment elle s'appelle ;
• comment on livre une version, comment on corrige en urgence ;
• merge ou rebase, et à quel moment.

Chaque équipe répond à ces questions par un workflow. Aucun n'est « le bon » : chacun répond à un souci précis, et le paie d'un prix. Passons-en trois en revue, du plus simple au plus outillé.

2. Une branche par sujet, une PR pour entrer

Le GitHub flow (2011), celui de la plupart des équipes aujourd'hui, et celui de notre atelier :

1. main est toujours en état de marche : on ne travaille jamais dessus ;
2. une branche courte par sujet, poussée tôt ; une PR dès qu'on veut un avis ;
3. review par un collègue + tests automatiques (Checks) ; puis merge, et on supprime la branche.

Le souci résolu : relire avant d'intégrer, garder main saine. Le prix : une étape de plus ; et une branche qui traîne trois semaines finit en conflit avec tout le monde.

3. Fork et PR : contribuer sans droit d'écriture

Même schéma que le précédent, mais la branche vit sur votre fork, pas dans le dépôt de référence :

upstream (le projet)  ◀── PR ───  origin (votre fork)  ◀── push ───  votre PC
        │                                                               ▲
        └──────────────────────── fetch upstream ───────────────────────┘

Le souci résolu : des milliers de contributeurs qui ne se connaissent pas (le noyau Linux, Python, numpy…). Le mainteneur ne donne les clés à personne ; n'importe qui peut proposer, lui seul décide.

Le prix : deux remotes à tenir à jour (git fetch upstream souvent), et votre fork qui prend du retard si vous l'oubliez.

C'est le modèle de l'atelier tout à l'heure : vous forkez raphaelpra/git-atelier-2026, vous poussez sur votre fork, vous proposez par PR.

Mettre sa PR à jour (1/2) : main a avancé

Vous avez ouvert votre PR ; depuis, j'ai mergé celles de deux camarades :

• votre branche part d'un main qui n'existe plus ; GitHub affiche This branch is out-of-date, ou This branch has conflicts si vous avez touché les mêmes lignes ;
• c'est à vous de la mettre à jour : c'est votre branche, sur votre fork.

Mettre sa PR à jour (2/2) : faire entrer le nouveau main

$ git fetch upstream                  ← rapatrie le main du dépôt de référence
$ git merge upstream/main             ← conflit ? corriger, git add, git commit
$ git push                            ← la PR se met à jour toute seule

• le même merge qu'en GIT1, avec une branche distante comme source ; vrai pour tous les workflows à PR, fork ou pas (origin/main au lieu d'upstream/main) ;
• l'autre école réécrit la branche par rebase pour garder la PR en ligne droite : annexe rebase.

stash : mettre de côté

Vous êtes au milieu d'une modification, et il faut changer de branche maintenant (git refuse : vos modifications entreraient en collision) :

$ git stash push -m "essai de graphique"     ← range les modifications, working tree propre
$ git switch main                            ← … le correctif urgent …
$ git switch analyse
$ git stash list
stash@{0}: On analyse: essai de graphique
$ git stash pop                              ← rétablit, et retire de la pile

• git stash tout court marche aussi, sans message : vous ne saurez plus dans une semaine ce que c'était ;
• -u pour embarquer aussi les fichiers non suivis (untracked) ;
• le stash est une pile qu'on oublie : au-delà de quelques minutes, préférez un vrai commit sur une branche, ou un worktree (partie 5).

blame : qui a écrit cette ligne, et pourquoi

Dans git-carnet-camille (hands-on 3) :

$ git blame recettes/crepes.md
7ac8892 (Raphael Prasquier 2026-09-10 10:00:00 +0200  3) - 250 g de farine
b6c47e3 (Camille           2026-10-15 09:00:00 +0200  4) - 4 œufs
7ac8892 (Raphael Prasquier 2026-09-10 10:00:00 +0200  5) - 50 cl de lait
7ac8892 (Raphael Prasquier 2026-09-10 10:00:00 +0200  6)
a9bfd1f (Raphael Prasquier 2026-09-10 12:00:00 +0200  7) Cuisson : 3 min par face, à feu vif.
$ git blame -L 4,7 recettes/crepes.md       ← seulement les lignes 4 à 7
$ git show b6c47e3                          ← le commit entier : son message, ses autres changements

Le nom est mal choisi : l'intérêt n'est pas de trouver un coupable, mais de retrouver le pourquoi d'une ligne étrange avant d'y toucher. Et ce pourquoi n'existe que si le message de commit le dit.

Écrire un message de commit

Corrige la moyenne quand la liste est vide          ← ≤ 50 caractères, à l'impératif

moyenne([]) levait ZeroDivisionError et faisait     ← une ligne vide, puis le pourquoi
planter le rapport du lundi. On renvoie désormais
None, que l'appelant affiche comme « pas de données ».

• la première ligne complète la phrase « ce commit… » : « Ajoute la fiche stash », pas « ajouté fiche », ni « fix », ni « wip » ;
• le quoi est dans le diff ; le message dit le pourquoi, qu'on ne peut pas deviner en lisant le code ;
• un commit = un sujet : si le message contient « et », ce sont probablement deux commits (git add -p pour découper un fichier en morceaux) ;
• le lecteur, c'est celui qui fera blame dans six mois : le plus souvent, vous.

git commit sans -m ouvre l'éditeur : c'est là qu'on écrit un corps de message.

Le souci : un seul trio, une seule branche à la fois

Le trio de GIT1 n'existe qu'en un exemplaire : vous ne pouvez avoir qu'une branche extraite à la fois. Pour un humain, changer de tâche oblige à stash, à un commit « wip », ou à un second clone.

Pour des agents de code (Claude Code, Codex, Cursor…), qui travaillent seuls plusieurs minutes et que l'on lance à plusieurs, c'est rédhibitoire. Dans un seul dossier :

• leurs modifications se mélangent dans le même working tree ;
• l'index est partagé : le git add de l'un part dans le commit de l'autre ;
• si l'un fait git switch, les fichiers changent sous les pieds de tous les autres.

Il faut à chaque agent son propre trio, sans cloner trois fois le dépôt.

L'idée : un .git, plusieurs working trees

• chaque dossier a son trio complet et sa branche extraite ; tous partagent le même .git ;
• un commit fait dans projet-bug/ est immédiatement visible depuis projet/ (git log --all) : pas de push, pas de fetch ;
• créer un worktree coûte la place des fichiers extraits, pas celle de l'historique.

Un agent = un worktree = une branche = une PR

• les outils d'agents font souvent ce worktree add pour vous : il faut savoir ce qu'ils font dessous, pour ranger, retrouver un travail, ou reprendre la main ;
• chaque agent a son dossier, sa branche, ses tests : rien ne se mélange, et un agent qui s'égare se jette avec son worktree, sans toucher aux autres ;
• la PR de la partie 4 retrouve tout son sens : c'est le moment où un humain relit ce qu'une machine a écrit. Plus on lance d'agents, plus la relecture devient le vrai travail.

C'est ainsi que je travaille au quotidien : une demi-douzaine de worktrees ouverts, un agent dans chacun, et mon temps passe en review.

🖐️ Hands-on 4 — deux tâches en parallèle (5 min)

Dans git-carnet :

1. git worktree add ../git-carnet-essai -b essai ;
2. cd ../git-carnet-essai, modifiez un fichier, add, commit ;
3. git worktree list ; puis cd ../git-carnet et git log --oneline --all : le commit d'essai est là, sans push ;
4. depuis git-carnet, essayez git switch essai : lisez le message ;
5. git worktree remove ../git-carnet-essai, puis git branch -d essai : refusé ? pourquoi ? (merge d'abord, ou -D).

Vous referez exactement cela dans l'atelier, étape 9, pour une deuxième fiche pendant que la première attend sa review.

Ce qu'il faut retenir

• un remote est un surnom pour un autre clone ; origin/main est la photo de sa position au dernier fetch ;
• fetch, regarder le graphe, puis décider ; pull = fetch + merge ;
• on intègre un autre dépôt en l'ajoutant comme remote : fetch, regarder, puis merge ;
• GitHub ajoute à git ce qui est social : forks, PR, review, protections ;
• git ne prend pas parti : chaque workflow répond à un souci, et le paie ; décidez-le en équipe, le premier jour ;
• mettre sa PR à jour : fetch upstream, puis merge upstream/main (le rebase : en annexe) ;
• worktree : un dossier par tâche (ou par agent), un seul .git.

Pour aller plus loin

• Pro Git, chapitres 2.5 (remotes), 3.5 (branches distantes), 5 (workflows distribués), 6 (GitHub) : https://git-scm.com/book/fr/v2 ;
• GitHub flow : https://docs.github.com/fr/get-started/using-github/github-flow ;
• git help worktree ; learngitbranching, onglet distant : le meilleur moyen de voir fetch, pull et push ;
• sur le site, les annexes rebase (rejouer ses commits, la règle d'or), reflog (retrouver un commit perdu), autres dépôts (cherry-pick, histoires sans ancêtre commun) et gh (GitHub en ligne de commande).

Pour toute question, vous pouvez me contacter par email : raphael@imagine-app.fr.