Änderungen mit git diff untersuchen

Änderungen mit 
git diff untersuchen
Ein Commit fasst nur zusammen, was sich verändert hat – doch bevor du überhaupt vormerkst oder committest, willst du genau wissen, welche Zeilen betroffen sind. Genau dafür ist 
git diff gedacht: Es macht Unterschiede zwischen zwei Zuständen deines Projekts sichtbar, ohne selbst irgendetwas zu verändern. 
git diff ist damit ein reines Lesewerkzeug – ideal, um vor jedem 
git add und jedem Commit einen letzten Kontrollblick zu werfen.
Drei Bereiche, drei Vergleiche
Erinnere dich an das Drei-Bereiche-Modell aus dem vorherigen Kapitel: Arbeitsverzeichnis, Index (Staging Area) und Repository. 
git diff vergleicht standardmäßig genau zwei dieser Bereiche – je nach Aufruf unterschiedliche.
Befehl
Vergleicht
Beantwortet die Frage
git diff
Arbeitsverzeichnis ↔ Index
„Was habe ich verändert, aber noch nicht vorgemerkt?“
git diff --staged (oder 
--cached)
Index ↔ letzter Commit
„Was würde ein Commit jetzt genau festhalten?“
git diff HEAD
Arbeitsverzeichnis ↔ letzter Commit
„Was unterscheidet sich insgesamt vom letzten Commit – egal ob vorgemerkt oder nicht?“
Diese Unterscheidung ist der Schlüssel zum Verständnis: 
git status sagt dir nur, dass etwas verändert wurde, 
git diff zeigt dir wie.
Der Standardfall: Arbeitsverzeichnis gegen Index
Nimm an, du hast eine Datei 
index.php bearbeitet, aber noch nichts mit 
git add vorgemerkt:
git diff
Die Ausgabe könnte so aussehen:
diff --git a/index.php b/index.php
index e69de29..f2c1a3d 100644
--- a/index.php
+++ b/index.php
@@ -1,3 +1,5 @@
 <?php
-echo "Hallo Welt";
+echo "Hallo, Git!";
+
+// Neue Zeile für die Begrüßung
Diese Ausgabe folgt dem sogenannten Unified-Diff-Format, das nicht nur Git, sondern auch viele andere Werkzeuge verwenden. Es lohnt sich, jeden Bestandteil einmal genau zu lesen:
diff --git a/... b/... – kennzeichnet die verglichenen Dateien; 
a steht für die alte, 
b für die neue Version.
index e69de29..f2c1a3d – zeigt die betroffenen Objekt-Hashes (dazu mehr im Kapitel über Git-Interna).
--- / 
+++ – markieren die alte bzw. neue Dateiversion.
@@ -1,3 +1,5 @@ – der sogenannte Hunk-Header. Er bedeutet: „Ab Zeile 1 wurden in der alten Datei 3 Zeilen, in der neuen Datei 5 Zeilen betrachtet.“
Zeilen mit 
- wurden entfernt, Zeilen mit 
+ wurden hinzugefügt, unveränderte Zeilen erscheinen ohne Präfix als Kontext.
Diese Kontextzeilen sind wichtig: Sie helfen dir, die Änderung im umgebenden Code einzuordnen, ohne die ganze Datei öffnen zu müssen.
Vorgemerkte Änderungen prüfen: 
--staged
Sobald du 
git add ausgeführt hast, zeigt der einfache 
git diff nichts mehr an – die Änderung liegt jetzt im Index, nicht mehr nur im Arbeitsverzeichnis. Um zu sehen, was genau ein Commit übernehmen würde, verwendest du:
git diff --staged
--cached ist ein reines Synonym und liefert dasselbe Ergebnis:
git diff --cached
Diese Unterscheidung zwischen unstaged und staged Diffs ist besonders bei selektivem Staging wertvoll (siehe Kapitel 5), wenn du bewusst nur einen Teil deiner Änderungen committen möchtest.
Alles auf einen Blick: 
git diff HEAD
Willst du unabhängig vom Staging-Status wissen, was sich seit dem letzten Commit insgesamt verändert hat – egal ob vorgemerkt oder nicht – hilft:
git diff HEAD
HEAD ist dabei ein Zeiger auf den aktuellen Commit, mit dem du später noch viel intensiver arbeiten wirst.
Einzelne Dateien oder Verzeichnisse vergleichen
git diff lässt sich immer auf konkrete Pfade einschränken. Das ist besonders bei größeren Projekten hilfreich, um den Fokus zu behalten:
git diff index.php
git diff src/
Mehrere Pfade lassen sich einfach aneinanderhängen:
git diff README.md composer.json
Kompakte Übersichten statt vollständiger Diffs
Manchmal willst du nicht jede Zeile sehen, sondern nur wissen, welche Dateien betroffen sind und wie stark:
git diff --stat
 index.php | 4 ++--
 README.md | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)
Für eine reine Auflistung der geänderten Dateinamen eignen sich:
git diff --name-only
git diff --name-status
--name-status ergänzt zusätzlich ein Kürzel wie 
M (modified), 
A (added) oder 
D (deleted) – praktisch für Skripte oder einen schnellen Überblick.
Wortweise statt zeilenweise vergleichen
Bei Prosatexten, Dokumentation oder Konfigurationsdateien ist eine zeilenbasierte Darstellung oft unübersichtlich, wenn nur ein einzelnes Wort geändert wurde. Hier hilft der Wortmodus:
git diff --word-diff
Er markiert nicht ganze Zeilen, sondern einzelne geänderte Wortfolgen mit 
[-alt-] und 
{+neu+} – deutlich präziser für kleinteilige Textänderungen.
Vorausblick: Commits und Branches vergleichen
git diff beschränkt sich nicht auf die drei lokalen Bereiche. Es lassen sich ebenso zwei beliebige Commits, Branches oder Tags gegenüberstellen, etwa mit:
git diff main feature/login
Diese Fähigkeit wird im Kapitel „Historie lesen, durchsuchen und vergleichen“ ausführlich vertieft – an dieser Stelle reicht es, zu wissen, dass 
git diff dafür dieselbe Syntax und dieselbe Ausgabe-Logik verwendet wie beim Vergleich von Arbeitsverzeichnis und Index.
Diff-Ausgaben besser lesbar machen
Auf vielen Windows-Terminals lohnt es sich, farbige Ausgaben zu aktivieren, falls sie nicht bereits standardmäßig aktiv sind:
git config --global color.diff auto
Für sehr lange Diffs kann zusätzlich ein Pager wie 
less hilfreich sein, den Git unter Windows über Git Bash automatisch mitbringt. Falls die Ausgabe im Terminal umbricht oder unübersichtlich wirkt, ist das ein guter Moment, um zur grafischen Diff-Ansicht in PhpStorm zu wechseln – dort erscheinen alte und neue Version übersichtlich nebeneinander, farblich hervorgehoben und mit Navigationspfeilen zwischen den Änderungsblöcken. Wie dieser Workflow konkret aussieht, zeigt der letzte Abschnitt dieses Kapitels.
Zusammenfassung
git diff ist dein wichtigstes Werkzeug, um Änderungen vor dem Staging und vor dem Commit kritisch zu prüfen. Die zentrale Faustregel lautet:
Kein Argument → Arbeitsverzeichnis gegen Index (unstaged Änderungen).
--staged/
--cached → Index gegen letzten Commit (was der nächste Commit enthält).
HEAD → Arbeitsverzeichnis gegen letzten Commit (alles zusammen).
Wer diese drei Varianten sicher unterscheidet, vermeidet eine der häufigsten Anfängerverwirrungen in Git: die Frage, warum eine erwartete Änderung im Diff plötzlich nicht mehr auftaucht, obwohl die Datei sichtbar verändert wurde. 🔍