Git 1 – les bases

Au programme

Vous faites déjà add, commit, push pour pe-homework, par recette. Aujourd'hui, nous allons comprendre ce que ces trois mots font vraiment, et apprendre à défaire une bêtise sans rien perdre.

Ouvrez un terminal dès maintenant : git --version doit répondre (2.40 ou plus).

Pourquoi git ? Un peu d'histoire

• 2005 : Linus Torvalds écrit git en quelques semaines pour gérer le code du noyau Linux, après la perte de l'outil propriétaire qu'il utilisait ;
• objectif : rapide, fiable, et sans serveur central obligatoire ;
• aujourd'hui : l'outil de versionnage de quasiment tout le logiciel libre et de l'industrie, et le socle de GitHub, GitLab, etc.

Ce que git vous apporte, à l'usage :

1. un historique : qui a changé quoi, quand, pourquoi ;
2. une machine à remonter le temps : rien de commité n'est jamais vraiment perdu ;
3. le travail en parallèle : plusieurs pistes (branches) sur le même projet ;
4. la collaboration : partager, relire, fusionner (ce sera GIT2).

Deux idées qui changent tout

Un commit est une photo complète (snapshot) du projet, pas une liste de modifications. Git range chaque fichier une seule fois, et un commit ne fait que pointer vers les bonnes versions.

commit 1        commit 2        commit 3
README v1       README v1       README v2
crepes v1       crepes v2       crepes v2
                                tarte  v1

Git est distribué : votre dossier contient tout l'historique, pas une copie de travail reliée à un serveur. GitHub n'est qu'un clone parmi d'autres, que l'on a choisi comme point de rendez-vous.

En clair : sans réseau, tout marche ; et push n'est qu'une synchronisation.

Le trio : working tree, index, HEAD

C'est LA slide de la séance. Git jongle en permanence avec trois « états » de votre projet :

Presque toutes les commandes du jour déplacent des choses entre ces trois cases. Quand une commande vous surprend, demandez-vous : « laquelle des trois vient-elle de toucher ? »

Le trio en mouvement

   working tree  ──── git add ────▶   index   ──── git commit ────▶   HEAD
   (vos fichiers)                  (préparé)                        (historique)
        ▲                              │                                 │
        └──── git restore <f> ─────────┘ (index → fichier)               │
        ▲                                                                │
        └───── git restore --staged <f> : HEAD → index (l'inverse d'add) ┘

• git status compare les trois et vous dit ce qui diffère ;
• git diff compare working tree et index ; git diff --staged compare index et HEAD.

L'index vous permet de ne commiter qu'une partie de ce que vous avez modifié.

Créer un dépôt : init, status

$ mkdir carnet && cd carnet
$ git init -b main
Initialized empty Git repository in /home/vous/carnet/.git/
$ git status
On branch main
No commits yet
nothing to commit (create/copy files and use "git add" to track)

• tout git vit dans le dossier caché .git/ ; supprimez-le et le projet redevient un dossier ordinaire ;
• -b main fixe le nom de la première branche (sinon master selon votre configuration) ;
• git status est la commande à taper avant et après chaque autre commande, le temps d'apprendre.

Enregistrer : add, commit

$ echo "# Carnet de recettes" > README.md
$ git status -s
?? README.md                       ← inconnu de git (untracked)
$ git add README.md
$ git status -s
A  README.md                       ← dans l'index, prêt à être commité
$ git commit -m "Crée le carnet de recettes"
[main (root-commit) a7d3639] Crée le carnet de recettes
 1 file changed, 1 insertion(+)

add copie le fichier dans l'index ; commit prend une photo de l'index et la range dans l'historique, avec un message, un auteur et une date. Le fichier n'a pas bougé sur le disque.

🖐️ Hands-on 1 — premier commit (5 min)

Dans un dossier neuf (il servira de bac à sable pour toute la matinée) :

1. mkdir bac-a-sable && cd bac-a-sable && git init -b main
2. créez notes.md avec une ligne de texte (éditeur ou echo) ;
3. git status, puis git add notes.md, puis git status : lisez la différence ;
4. git commit -m "Première note" ;
5. modifiez notes.md, ajoutez une ligne, puis git status : que dit git ?
6. git add notes.md && git commit -m "Deuxième note", puis git log --oneline.

Si git commit ouvre un éditeur inconnu : Échap, :q!, puis git config --global core.editor "code --wait".

Lire git status

$ git status
On branch main
Changes to be committed:                 ← dans l'index (vert)
  (use "git restore --staged <file>..." to unstage)
	modified:   README.md
Changes not staged for commit:           ← dans le working tree seulement (rouge)
  (use "git add <file>..." to update what will be committed)
	modified:   recettes/crepes.md
Untracked files:                         ← git ne les connaît pas encore
	notes.tmp

Git vous souffle à chaque fois la commande pour revenir en arrière : lisez ces lignes entre parenthèses, elles sont la meilleure documentation du jour. La forme courte, git status -s, tient sur deux colonnes : index à gauche, working tree à droite.

L'historique : git log

$ git log --oneline
a9bfd1f Précise la cuisson des crêpes
093450a Ajoute la tarte aux pommes et le sommaire
7ac8892 Ajoute la recette des crêpes
a7d3639 Crée le carnet de recettes
$ git log --oneline --graph --all         ← toutes les branches, avec le dessin
$ git log --stat -2                        ← les fichiers touchés par les 2 derniers
$ git log -p -- recettes/crepes.md         ← l'histoire d'un seul fichier, avec les diffs

Chaque commit est identifié par un hash SHA-1 de 40 caractères (a9bfd1f59efa…) ; les 7 premiers suffisent pour le désigner. Un commit connaît son parent : c'est cette chaîne qui fait l'historique.

Voir les changements : diff, show

$ git diff                    # working tree ↔ index : ce que je n'ai pas encore "add"
$ git diff --staged           # index ↔ HEAD : ce que le prochain commit contiendra
$ git diff HEAD~1             # working tree ↔ avant-dernier commit
$ git show a9bfd1f            # un commit : son en-tête + son diff
diff --git a/recettes/crepes.md b/recettes/crepes.md
@@ -4,6 +4,6 @@
 - 50 cl de lait

-Cuisson : 2 min par face.
+Cuisson : 3 min par face, à feu vif.

- : la ligne d'avant, + : celle d'après ; @@ -4,6 +4,6 @@ situe le bloc (à partir de la ligne 4, 6 lignes). HEAD~1 désigne le parent de HEAD, HEAD~2 le grand-parent.

Ce qu'on ne versionne pas : .gitignore

Un fichier texte à la racine, commité avec le projet, un motif par ligne :

# un commentaire commence la ligne (pas en fin de ligne !)
__pycache__/
*.pyc
.venv/
.ipynb_checkpoints/
# les images produites par le code, sauf celle du projet
*.png
!logo.png

Règle : on ne commite pas ce qui se régénère (caches, environnements, sorties de calcul) ni ce qui est secret (clés, mots de passe). Les fichiers ignorés disparaissent de git status ; un fichier déjà commité reste suivi même si vous l'ajoutez ensuite au .gitignore (git rm --cached <f> pour l'oublier).

Un commit est un snapshot, pas un diff

$ git cat-file -p a9bfd1f          # « montre-moi cet objet »
tree c52f0cf1c8177960488734248311264a2539ee65
parent 093450a4632ed7c6f08ed84c9b912c924e418ade
author Raphael Prasquier <raphael@imagine-app.fr> 1789034400 +0200

Précise la cuisson des crêpes

Un commit, c'est : un tree (la photo de l'arborescence), son parent, un auteur, un message. Le diff que vous montre git show est recalculé entre deux photos.

Conséquences utiles : revenir à n'importe quel commit est instantané ; deux commits qui contiennent le même fichier le stockent une seule fois. Le détail (.git/objects, blobs, trees) est dans l'annexe « les internes ».

Une branche est un pointeur

Une branche n'est pas une copie du projet : c'est un fichier de 41 octets dans .git/refs/heads/ qui contient le hash d'un commit. HEAD pointe vers la branche courante.

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

À chaque commit, la branche courante avance d'un cran. Créer une branche coûte donc… 41 octets, et il n'y a aucune raison de s'en priver : une branche par idée, par essai, par bug.

Changer de branche : switch (et checkout)

$ git branch                      # liste ; * marque la branche courante
$ git branch garniture            # crée, sans y aller
$ git switch garniture            # y va : HEAD bouge, les fichiers suivent
$ git switch -c sauce             # crée ET y va (le plus fréquent)
$ git switch main                 # retour
$ git branch -d garniture         # supprime (refuse si non fusionnée ; -D force)

git switch (2019) remplace l'ancien git checkout <branche>, que vous verrez partout dans les tutoriels et dans learngitbranching. Même effet ; checkout faisait aussi le travail de restore, d'où son remplacement par deux commandes plus claires.

Avant de changer de branche : git status propre, ou git refusera si vos modifications entrent en collision.

HEAD détachée (detached HEAD)

$ git switch --detach 7ac8892      # ou : git checkout 7ac8892
HEAD is now at 7ac8892 Ajoute la recette des crêpes
$ git status
HEAD detached at 7ac8892

Vous êtes « sur » un commit, plus sur une branche : pratique pour regarder le passé, tester une ancienne version. Cependant, si vous commitez ici, aucune branche n'avance : ces commits ne sont retenus que par le reflog.

Deux sorties propres :

• git switch main pour rentrer ;
• git switch -c essai pour garder ce que vous venez de faire sur une nouvelle branche.

🖐️ Hands-on 2 — branches (5 min)

Toujours dans bac-a-sable :

1. git switch -c idees, puis créez idees.md avec une ligne, add, commit ;
2. ls : le fichier est là ; git switch main, puis ls : où est-il passé ?
3. git log --oneline --graph --all : repérez HEAD, main, idees ;
4. cat .git/HEAD, puis cat .git/refs/heads/idees : que contiennent-ils ?
5. git switch --detach HEAD~1, git status, puis revenez sur main.

Question : au point 2, pourquoi idees.md a-t-il disparu sans message d'erreur ?

Fusionner : merge fast-forward

Sur main, on veut rapatrier garniture. Si main n'a pas bougé depuis la création de la branche, git se contente d'avancer le pointeur : c'est un fast-forward, aucun commit créé.

$ git switch main
$ git merge garniture
Updating a9bfd1f..12ed6ff
Fast-forward
 recettes/crepes.md | 5 +++++
 1 file changed, 5 insertions(+)

avant : … ← a9bfd1f (main) ← 12ed6ff (garniture)
après : … ← a9bfd1f ← 12ed6ff (main, garniture)

Fusionner : le merge commit

Si les deux branches ont avancé chacune de leur côté, git crée un commit à deux parents qui réunit les deux photos :

$ git merge sauce
Merge made by the 'ort' strategy.
 README.md | 4 ++++
$ git log --oneline --graph
*   fcd6c7a Merge branch 'sauce'
|\
| * 178222f Annonce la section sauces
* | 12ed6ff Ajoute les garnitures des crêpes
* | a9bfd1f Précise la cuisson des crêpes
|/
* 093450a Ajoute la tarte aux pommes et le sommaire

Git a comparé les deux branches à leur ancêtre commun (093450a) : chacune a changé un fichier différent, il a pris les deux. Pas de conflit.

Le conflit : anatomie

Un conflit survient quand les deux branches ont modifié la même ligne depuis l'ancêtre commun. Git ne devine pas : il vous laisse trancher.

$ git merge cuisson
Auto-merging recettes/crepes.md
CONFLICT (content): Merge conflict in recettes/crepes.md
Automatic merge failed; fix conflicts and then commit the result.

<<<<<<< HEAD
Cuisson : 3 min par face, à feu vif.      ← la version de ma branche (main)
=======
Cuisson : 1 min 30 par face.              ← la version de la branche fusionnée
>>>>>>> cuisson

Le reste du fichier est déjà fusionné ; seul ce bloc attend votre décision.

Le conflit : résolution

1. ouvrez le fichier, choisissez (ou combinez) et supprimez les trois marqueurs :

   Cuisson : 1 min 30 par face, à feu vif.
   

2. dites à git que c'est réglé : git add recettes/crepes.md ;
3. git status doit dire All conflicts fixed but you are still merging ;
4. terminez : git commit (le message « Merge branch 'cuisson' » est pré-rempli).

Pour renoncer à tout moment : git merge --abort remet le dépôt comme avant le merge.

Un conflit n'est pas une panne : c'est git qui vous pose une question. Grep <<<<<<< avant de commiter, il en reste toujours un.

🖐️ Hands-on 3 — un conflit exprès (5 min)

1. sur main, changez la première ligne de notes.md, add, commit ;
2. git switch idees, changez cette même première ligne autrement, add, commit ;
3. git switch main && git merge idees : lisez le message ;
4. git status, puis cat notes.md : repérez les trois marqueurs ;
5. résolvez dans l'éditeur, git add notes.md, git commit ;
6. git log --oneline --graph : le commit à deux parents est là.

Bonus si vous avez fini : refaites l'étape 3 sur une autre ligne et constatez que ce n'est plus un conflit.

Défaire : la carte

Avant de défaire, une seule question : est-ce que ce commit a déjà été poussé ? Si oui, revert ; sinon, tout est permis.

restore : le working tree et l'index

$ echo boom >> README.md
$ git status -s
 M README.md
$ git restore README.md            # ⚠ irréversible : la modification n'existait nulle part ailleurs
$ git status -s
$ git add README.md                # …supposons qu'on l'ait ajouté par erreur
$ git restore --staged README.md   # l'index redevient égal à HEAD ; le fichier est intact
$ git restore --source HEAD~1 recettes/tarte.md   # ramène la version d'il y a un commit

restore <f> recopie l'index dans le fichier ; restore --staged <f> recopie HEAD dans l'index. Vous reconnaissez les deux flèches "retour" du schéma du trio. Ancienne forme : git checkout -- <f>.

reset : déplacer HEAD (et la branche)

git reset <commit> fait reculer la branche courante ; le mode dit ce qu'on fait des deux autres cases.

Mode	HEAD	index	working tree
--soft	recule	inchangé (les changements restent "add")	inchangé
--mixed (défaut)	recule	recule	inchangé (les changements restent, non "add")
--hard	recule	recule	recule modifications non commitées perdues

$ git reset --soft HEAD~1     # "décommite" : tout est prêt à être recommité, autrement
$ git reset HEAD~1            # défait le commit et le add ; les fichiers restent modifiés
$ git reset --hard HEAD~1     # le commit disparaît de la branche… mais pas de git (cf. reflog)

revert : annuler sans réécrire

$ git revert a9bfd1f
[main f65d87e] Revert "Précise la cuisson des crêpes"
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git log --oneline -2
f65d87e Revert "Précise la cuisson des crêpes"
a9bfd1f Précise la cuisson des crêpes

revert ne supprime rien : il crée un nouveau commit qui applique le changement inverse. L'historique reste vrai, et c'est la seule façon correcte d'annuler un commit que d'autres ont déjà récupéré (poussé sur GitHub, par ex.).

reset réécrit le passé ; revert ajoute au présent. Sur pe-homework, une fois poussé : revert.

reflog : le filet de sécurité

Git note chaque déplacement de HEAD et le garde des semaines (30 à 90 jours), y compris vers des commits que git log ne montre plus :

$ git reset --hard HEAD~2
HEAD is now at 12ed6ff Ajoute les garnitures des crêpes
$ git reflog
12ed6ff HEAD@{0}: reset: moving to HEAD~2
dd98832 HEAD@{1}: commit (merge): Merge branch 'cuisson'
fcd6c7a HEAD@{2}: merge sauce: Merge made by the 'ort' strategy.
$ git reset --hard HEAD@{1}          # ou : git reset --hard dd98832
HEAD is now at dd98832 Merge branch 'cuisson'

Retenez bien : un commit n'est jamais perdu tant qu'il figure dans le reflog. Ce qui est perdu, c'est ce qui n'a jamais été commité (restore, reset --hard sur des modifications en cours).

🖐️ Hands-on 4 — perdre puis retrouver (5 min)

1. git log --oneline : notez le hash du commit du haut ;
2. git reset --hard HEAD~1 ; git log --oneline : il a disparu, et le fichier avec ;
3. git reflog : retrouvez-le (ligne HEAD@{1}) ;
4. git reset --hard HEAD@{1} ; git log --oneline : il est revenu ;
5. git switch -c avant-reset HEAD@{2} : une branche posée sur un ancien état, pour le garder.

Question : à l'étape 2, où était passé ce commit, physiquement ? (indice : ls .git/objects)

Les 3 pièges du jour

1. Commiter sans regarder. git add . ramasse tout : le .venv/, les données de 300 Mo, le fichier avec la clé API. Réflexe : git status puis git diff --staged avant git commit.

2. Confondre reset --hard et restore. restore jette des modifications jamais commitées : c'est définitif. reset --hard jette des commits : c'est rattrapable par reflog. Le vrai danger est donc restore (et reset --hard avec du travail non commité).

3. Réécrire ce qui est poussé. reset ou --amend sur un commit déjà sur GitHub, puis push refusé ; ou pire, push --force sur le travail des autres. Réflexe : poussé ⇒ revert.

Bonus : un conflit résolu se termine par git add + git commit, sinon vous restez « en cours de merge » pour toujours.

Le dépôt distant : origin, push, pull

Ce que vous faites déjà pour pe-homework, en clair :

$ git remote -v                                  # les dépôts distants connus
origin  git@github.com:vous/pe-homework.git (fetch)
origin  git@github.com:vous/pe-homework.git (push)
$ git push -u origin main         # 1re fois : envoie main, et "lie" main à origin/main
$ git push                        # ensuite : envoie les nouveaux commits de la branche liée
$ git pull                        # récupère les commits de origin/main et les fusionne (merge)

• origin est juste le nom par défaut du clone sur GitHub ; il pourrait s'appeler autrement ;
• origin/main est un pointeur local qui mémorise où en était GitHub la dernière fois ;
• push est refusé si GitHub a des commits que vous n'avez pas : pull d'abord.

Créer un dépôt sur GitHub depuis un projet local

Le chemin que le TP vous fera prendre (identique à pe-homework) :

1. sur GitHub : New repository, nom git-homework, sans README ni .gitignore (le projet existe déjà) ;
2. dans le terminal, à la racine du projet :

   $ git remote add origin git@github.com:VOUS/git-homework.git
   $ git push -u origin main
   

3. rechargez la page GitHub : vos commits sont là ; vérifiez avec un clone frais dans /tmp.

Le reste (fetch, branches de suivi, fork, pull request, rebase, review) est le programme de GIT2.

Et dans VS Code

Tout ce que nous avons fait au terminal existe dans la vue Source Control (Ctrl+Shift+G) :

C'est confortable, et je m'en sers. Cependant, quand quelque chose "ne marche pas", c'est le terminal qui vous dira pourquoi : gardez les deux ouverts.

Retenez bien

• trois cases : working tree → index → HEAD, franchies par add puis commit ; status et diff les comparent ;
• un commit est une photo complète, identifiée par un hash, qui connaît son parent ;
• une branche est un pointeur de 41 octets ; switch déplace HEAD et les fichiers suivent ;
• merge : fast-forward si l'une des branches n'a pas bougé, sinon commit à deux parents ; un conflit se règle à la main puis add + commit ;
• défaire : restore (fichiers), reset (commits locaux), revert (commits poussés), reflog (tout retrouver) ;
• avant commit : git status ; avant push : git log --oneline.

TP (1 h) : mon premier projet sous git

Sujet complet : tp.md sur le site du cours. En résumé :

1. un petit projet à vous (carnet de recettes, mini-script Python + README…) ;
2. 5-6 commits propres, un .gitignore pour les fichiers générés ;
3. une branche, un merge fast-forward ; une seconde branche avec conflit, résolu ;
4. un revert, puis un reset --hard suivi d'une récupération par reflog ;
5. le dépôt poussé sur GitHub sous le nom exact git-homework (public, ou privé avec raphaelpra en collaborateur), vérifié par un clone frais.

Rien n'est noté sur ce TP. En revanche, c'est dans git-homework que vous déposerez le bonus.

Bonus : learngitbranching

https://learngitbranching.js.org/?NODEMO=&locale=fr_FR : un git dessiné, à jouer dans le navigateur (il parle checkout, c'est l'ancien nom de switch).

• +1 point : les 20 niveaux de l'onglet principal (intro1-4, rampup1-4, move1-4, mixed1-5, advanced1-3) ;
• +1 point de plus : les 16 niveaux de l'onglet distant (remote1-8, remoteAdvanced1-8) ;
• un niveau résolu avec show solution n'est pas compté par le jeu.

Pour rendre : sur le site, F12 → Console, tapez copy(exportLevelProgress()), collez dans un fichier solvedMap.json à la racine de git-homework, commit, push. Mercredi 21 octobre 2026, 18 h.

C'est déclaratif : je vous fais confiance. La note Git = quiz de GIT2 (/20) + bonus, plafonnée à 20.

Pour aller plus loin

• Pro Git, S. Chacon & B. Straub, gratuit et en français : https://git-scm.com/book/fr/v2 ; les chapitres 2 et 3 couvrent exactement cette séance, le chapitre 10 l'annexe « les internes » ;
• learngitbranching : https://learngitbranching.js.org/?NODEMO=&locale=fr_FR — le bonus, mais aussi la meilleure façon de voir rebase avant GIT2 ;
• Oh Shit, Git!?! : https://ohshitgit.com/fr — « j'ai fait une bêtise, comment je répare ? », par situation ;
• git help <commande> ou man git-reset : la documentation officielle est bonne, et locale.

Prochaine séance, GIT2 (22 octobre) : quiz, worktree, remotes, fork et pull request, rebase, atelier collaboratif.

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