Distinguer git diff et git diff –staged
Git conserve trois versions de chaque fichier suivi : celle du dernier commit, celle de l’index et celle de votre répertoire de travail. Deux commandes les comparent. git diff compare le répertoire de travail à l’index : les changements que vous pourriez encore indexer. git diff --staged compare l’index au dernier commit : les changements que contiendra votre prochain commit. --cached fait la même chose : la documentation de Git présente --staged comme un synonyme de cette option. Si l’index est nouveau pour vous, le guide de git add et du staging l’explique d’abord.
Les exemples utilisent orbit-api. Vous avez modifié src/search.ts à deux endroits et, avec git add -p, vous n’avez indexé que le premier. Voici ce qu’affichent les deux commandes. Les sorties sont celles de Git 2.23, en anglais ; Git 2.30 et 2.54 affichent le même texte.
git diffdiff --git a/src/search.ts b/src/search.ts
index e6eaa83..87aea95 100644
--- a/src/search.ts
+++ b/src/search.ts
@@ -24,5 +24,7 @@ export function search(index: Map<string, Project[]>, query: string): Project[]
hits.set(project.id, project);
}
}
- return [...hits.values()].sort((a, b) => a.name.localeCompare(b.name));
+ return [...hits.values()]
+ .filter((hit) => !hit.archived)
+ .sort((a, b) => a.name.localeCompare(b.name));
}git diff --stageddiff --git a/src/search.ts b/src/search.ts
index 24c85be..e6eaa83 100644
--- a/src/search.ts
+++ b/src/search.ts
@@ -8,6 +8,7 @@ export function buildIndex(projects: Project[]): Map<string, Project[]> {
const index = new Map<string, Project[]>();
for (const project of projects) {
for (const token of project.name.toLowerCase().split(/\s+/)) {
+ if (token === "") continue;
const bucket = index.get(token) ?? [];
bucket.push(project);
index.set(token, bucket);Les deux sorties contiennent des blocs différents. git diff montre la modification de search, qui n’est pas indexée, et git diff --staged montre celle de buildIndex, qui l’est. git diff --cached affiche exactement le même texte que git diff --staged. Le git diff simple a une limite à connaître : il ne liste jamais un fichier non suivi. Un nouveau fichier n’apparaît dans git diff --staged qu’après un git add.
Lire ajouts, suppressions et contexte
Prenez la sortie de git diff ci-dessus et lisez-la depuis le début :
diff --git a/src/search.ts b/src/search.tsnomme le fichier comparé.index e6eaa83..87aea95 100644donne les identifiants abrégés des deux versions : celle de l’index, puis celle de votre répertoire de travail.--- a/src/search.tset+++ b/src/search.tsdésignent l’ancien et le nouveau côté.@@ -24,5 +24,7 @@ouvre un bloc. Côté ancien, il couvre 5 lignes à partir de la ligne 24, et côté nouveau 7 lignes à partir de la ligne 24. Le texte qui suit, ici la signature desearch, est une ligne proche qui aide à situer le bloc.- Une ligne qui commence par
-a été supprimée. Une ligne qui commence par+a été ajoutée. Une ligne qui commence par une espace est du contexte : inchangée, affichée pour que vous voyiez où se situe la modification.
Dans ce bloc, une ligne a été supprimée et trois ont été ajoutées, ce qui explique le passage de 5 à 7 lignes. Une ligne modifiée apparaît toujours comme une ligne - suivie de son remplacement en +.
Les numéros de ligne dépendent de ce que vous comparez. git diff HEAD compare le répertoire de travail au dernier commit : il affiche donc les deux blocs, et écrit l’en-tête du second @@ -23,5 +24,7 @@. Dans le git diff simple, l’ancien côté est l’index, qui contient déjà la ligne ajoutée par le premier bloc : le même bloc commence donc à la ligne 24 des deux côtés.
Reconnaître un fichier partiellement indexé
git status -s vous le dit d’un coup d’œil :
git status -sMM src/search.tsLa première colonne décrit l’index et la seconde le répertoire de travail. MM signifie que le fichier est modifié aux deux endroits : une partie est indexée, une partie ne l’est pas. Un fichier affiché M est entièrement indexé, et un fichier affiché M n’a rien d’indexé. Pour mesurer chaque côté, comparez les résumés :
git diff --cached --stat
git diff --stat src/search.ts | 1 +
1 file changed, 1 insertion(+)
src/search.ts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)Le premier résumé est la partie indexée : une ligne ajoutée. Le second est ce qui reste : une ligne supprimée et trois ajoutées. Regardez de nouveau les lignes index des deux diffs. git diff --staged se terminait à e6eaa83, et git diff part de ce même e6eaa83 : c’est la version indexée du fichier, située entre la version commitée (24c85be) et celle de votre disque (87aea95).
Valider le prochain commit dans GitMini
GitMini garde les deux mêmes vues séparées. Chaque diff porte une étiquette de source dans son en-tête, et les deux qui comptent ici sont Staged et Unstaged. Staged compare le dernier commit à l’index, comme git diff --staged. Unstaged compare l’index à votre répertoire de travail, comme git diff. Les libellés de l’interface restent en anglais.
Cliquez sur un fichier de la liste Staged pour ouvrir son diff Staged, et sur un fichier de la liste Unstaged pour ouvrir son diff Unstaged. Un fichier partiellement indexé figure dans les deux listes : vous ouvrez chaque côté depuis sa propre liste, comme sur la capture. L’en-tête affiche aussi le nombre de lignes ajoutées et supprimées, par exemple +5 −2. Quand il ne reste plus rien d’un côté, GitMini le dit : « No staged changes remain for this file. » ou « No unstaged changes remain for this file. »
Les boutons de bloc suivent la source. Dans un diff Unstaged, chaque bloc propose Stage hunk et Discard hunk. Dans un diff Staged, il propose Unstage hunk. Côté terminal, l’outil correspondant est git add -p. Une fois le commit fait, le même fichier s’ouvre depuis les détails du commit avec une étiquette Commit, et le guide de git show couvre l’équivalent en terminal.
Sources
- Documentation Git : git-diff (en anglais), consulté le 4 octobre 2026.
- Pro Git : Indexation interactive, consulté le 4 octobre 2026.
- README du produit GitMini, consulté le 4 octobre 2026.