git status

Der Befehl git status beantwortet eine einzige, beständige Frage während du arbeitest: Was hat sich seit meinem letzten Commit geändert, und was ist bereit zum Committen? Es ist der Befehl, den du öfter ausführst als jeden anderen — vor dem Stagen, vor dem Committen und jedes Mal, wenn du den Überblick verlierst, wo eine Datei steht. Diese Seite erklärt die drei Zustände, in denen sich eine Datei befinden kann, wie man sowohl die lange als auch die kurze Ausgabe liest und welche Optionen status skriptfähig machen.

Was git status anzeigt

git status zeigt den Zustand von zwei Dingen: dem Arbeitsverzeichnis (die Dateien auf der Festplatte, die du bearbeitest) und dem Staging-Bereich, auch Index genannt (der Snapshot, den du für den nächsten Commit vorbereitest). Es zeigt dir, welche Dateien:

• Gestaged sind — Änderungen, die mit git add hinzugefügt wurden und für den nächsten Commit bereit sind.
• Nicht gestaged (geändert) sind — verfolgte Dateien, die du geändert, aber noch nicht hinzugefügt hast.
• Nicht verfolgt sind — neue Dateien, die Git noch nie gesehen hat und nicht verfolgt.

Was git status nicht anzeigt, ist die Commit-Historie. Es sagt nichts über frühere Commits, zusammengeführte Branches oder wer was geändert hat — dafür verwendest du git log. Es zeigt auch nicht den Inhalt deiner Änderungen; um die genauen hinzugefügten und entfernten Zeilen zu sehen, verwende git diff. Kurz gesagt fasst status die Wirkung von git add und git commit auf deine aktuellen Dateien zusammen.

Grundlegende Verwendung

Der Befehl nimmt in seiner häufigsten Form keine Argumente an:

git status

In einem sauberen Repository ohne ausstehende Änderungen teilt Git dir dies mit:

On branch master
nothing to commit, working tree clean

Die lange Ausgabe lesen

Die Standardausgabe (auch mit --long erreichbar) ist das ausführliche, menschenlesbare Format. Verfolge eine Datei durch ihren Lebenszyklus, um zu sehen, wie jeder Abschnitt erscheint.

Eine brandneue Datei, die Git noch nie gesehen hat, ist nicht verfolgt:

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	w3docs.txt

nothing added to commit but untracked files present (use "git add" to track)

Nach git add w3docs.txt wechselt dieselbe Datei unter Changes to be committed — sie ist nun gestaged:

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   w3docs.txt

Sobald du git commit ausführst, ist das Arbeitsverzeichnis wieder sauber. Bearbeite nun w3docs.txt und erstelle eine zweite Datei new.txt. Eine verfolgte Datei, die du änderst, erscheint unter Changes not staged for commit, während die brandneue Datei unter Untracked files bleibt:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   w3docs.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	new.txt

no changes added to commit (use "git add" and/or "git commit -a")

Beachte, dass die Hinweise in Klammern echte, ausführbare Vorschläge sind: Git zeigt dir bei jedem Schritt, wie du die Stagingvorbereitung rückgängig machst, Änderungen verwirfst oder Dateien hinzufügst.

Das Kurzformat

Wenn du weißt, was die Abschnitte bedeuten, wird das lange Format unübersichtlich. Das Flag -s (oder --short) verdichtet alles auf eine Zeile pro Datei:

git status -s

Für den obigen Zustand (eine geänderte verfolgte Datei, eine neue nicht verfolgte Datei) gibt es aus:

 M w3docs.txt
?? new.txt

Jeder Eintrag hat einen zweistelligen Statuscode. Die linke Spalte ist der Staging-Bereich (der Index) und die rechte Spalte ist das Arbeitsverzeichnis:

Ein führendes Leerzeichen bedeutet „keine Änderung in dieser Spalte." Also bedeutet M geändert, aber nicht gestaged, M bedeutet, die Änderung ist gestaged, und MM bedeutet eine gestagede Änderung plus weitere nicht gestagede Bearbeitungen an derselben Datei.

Füge -b hinzu, um auch den aktuellen Branch und seine Tracking-Informationen auszugeben:

git status -sb

## master
 M w3docs.txt
?? new.txt

Ausgabe für Skripte: --porcelain

Wenn du git status aus einem Skript heraus lesen möchtest, parse nicht das kurze oder lange Format — beide können sich zwischen Git-Versionen ändern und werden von der Benutzerkonfiguration beeinflusst. Verwende stattdessen --porcelain. Es garantiert ein stabiles, maschinenlesbares Format:

git status --porcelain

 M w3docs.txt
?? new.txt

Die Spalten sind dieselben zweistelligen Codes wie im Kurzformat, aber das Format ist vertraglich stabil und damit sicher für Hooks, CI-Prüfungen und Shell-Eingabeaufforderungen. Kombiniere es mit -z, um jeden Eintrag mit einem NUL-Byte statt einem Zeilenumbruch zu beenden, was Dateinamen mit Leerzeichen oder Zeilenumbrüchen eindeutig hält.

Ignorierte Dateien anzeigen

Standardmäßig blendet git status Dateien aus, die von deinen .gitignore-Regeln erfasst werden — Build-Artefakte und Binärdateien wie .pyc, .obj, .exe oder Protokolldateien würden sonst die echten Änderungen überdecken. Um zu bestätigen, dass eine Datei ignoriert wird (anstatt einfach vergessen zu werden), füge --ignored hinzu:

git status --ignored

Mit einer .gitignore, die *.log enthält, und einer debug.log auf der Festplatte erscheint ein zusätzlicher Abschnitt:

Ignored files:
  (use "git add -f <file>..." to include in what will be committed)
	debug.log

Dies ist der schnellste Weg, eine Ignore-Regel zu debuggen, die mehr — oder weniger — als erwartet zutrifft.

Häufige Optionen

Warum du status oft prüfen solltest

Es ist gute Praxis, git status vor jedem git add und git commit auszuführen. Eine schnelle Prüfung deckt häufige Fehler auf: das Committen einer Datei, die du vergessen hast zu stagen, das versehentliche Stagen einer Debug-Datei oder das Committen auf dem falschen Branch. Da status nur das Repository liest und nie etwas ändert, ist es immer sicher, ihn auszuführen.

Nachdem du den Status gelesen hast, sind die natürlichen nächsten Schritte, die genauen Änderungen mit git diff zu untersuchen, einen Staging-Fehler mit git reset rückgängig zu machen oder, wenn du noch nicht begonnen hast, das Repository mit git init zu erstellen.

Übung