Les trois zones

Une modification traverse trois zones avant d'entrer dans l'historique. Presque toutes les incompréhensions de Git viennent de la deuxième, l'index, que les autres systèmes n'ont pas.

Lire git status

$ git status --short
M  src/lib/quiz.ts        ← modifié, dans l'index
 M src/lib/lab.ts         ← modifié, PAS dans l'index
MM content/index.mdx      ← une version dans l'index, une autre encore modifiée
?? notes.txt              ← non suivi

Deux colonnes : la première décrit l'index, la seconde le répertoire de travail. MM est le cas instructif — tu as ajouté une version à l'index, puis continué à éditer. Le commit prendra la version de l'index, pas celle du disque. C'est la source du grand classique : « j'ai commité, mais ma correction n'y est pas ».

git diff répond à deux questions différentes

git diff              # index → répertoire de travail : ce que tu n'as PAS encore ajouté
git diff --staged     # dépôt → index : ce qui partira au prochain commit

Le réflexe avant tout commit est git diff --staged : c'est la seule commande qui montre exactement ce qui va être enregistré.

Pourquoi l'index existe

Il permet de composer un commit au lieu de le subir. Tu as corrigé un bogue, renommé trois variables et ajouté une note personnelle ? Trois choses sans rapport, qui méritent des commits distincts — voire, pour la note, aucun.

$ git add -p src/lib/quiz.ts

-p propose les modifications morceau par morceau, avec y pour ajouter, n pour ignorer, s pour découper encore. C'est l'outil qui transforme un historique fourre-tout en un historique où chaque commit raconte une chose.

Le piège classique

git commit -a ajoute automatiquement les fichiers suivis modifiés, en court-circuitant l'index. Pratique, mais il ne prend pas les fichiers non suivis, ce qui produit l'autre classique : « j'ai créé le fichier, je l'ai commité, et il n'est pas là ». Un fichier nouveau doit toujours passer par git add.