Übersicht
git diff [<options>] [<commit>] [--] [<path>...]
Beschreibung
Der git diff-Befehl zeigt Unterschiede zwischen zwei Mengen von Dateiinhalten. Ohne Argumente vergleicht er den Working Tree mit der Staging Area und zeigt, was nicht gestaged ist. Mit --cached (oder --staged) vergleicht er die Staging Area mit dem jüngsten Commit. Mit einem oder zwei Commit-Argumenten vergleicht er diese Commits.
Diffs sind zentral für Code-Review, Debugging und das Verständnis von Historie. Git erzeugt standardmäßig Unified Diffs, kann aber auch wortbasierte Diffs, Color-Moved-Hervorhebung und Statistiken ausgeben. Für Binärdateien wird nur eine "Differs"-Zeile angezeigt, es sei denn, ein Binär-Diff-Driver ist konfiguriert.
Im täglichen Einsatz integriert sich git diff eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git diff --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.
Zu verstehen, wie git diff mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git diff hilft, alle drei zu vermeiden.
Häufige Optionen
| Option | Beschreibung |
|---|---|
--cached / --staged | Vergleicht den Index mit HEAD statt Working Tree mit Index. |
--stat | Zeigt eine Zusammenfassung der Einfügungen/Löschungen pro Datei. |
--name-only | Listet nur die Namen der unterschiedlichen Dateien auf. |
--word-diff | Hebt Änderungen auf Wortebene hervor. |
-w, --ignore-all-space | Ignoriert Whitespace-Unterschiede. |
--color-moved | Hebt verschobene Codeblöcke hervor. |
-U<n> | Zeigt n Kontextzeilen (Standard 3). |
Beispiele
git diff
# Ungestagte Änderungen im Working Tree
git diff --cached
# Für den nächsten Commit gestagte Änderungen
git diff main..feature
# Alle Unterschiede zwischen zwei Branches
git diff HEAD~3 HEAD -- src/
# Letzte drei Commits, beschränkt auf src/
Häufige Fehler
Das Vergessen von --cached beim Überprüfen, was gleich committet wird, ist eine klassische Verwirrung. Eine weitere ist die falsche Verwendung der Zwei-Punkt- vs. Drei-Punkt-Bereichssyntax: A..B sind "Unterschiede von A nach B", während A...B "Unterschiede von der Merge-Basis nach B" sind. Riesige reine Whitespace-Diffs nach Editor-Änderungen lassen sich mit -w zähmen.
Verwandte Befehle
git status, git log -p, git show, git range-diff