Weswegen
Tippen, um zu suchen
    Esc zum Schließen · Sofortsuche auf der ganzen Website

    Git-Status prüfen: git status verstehen und richtig lesen

    · Weswegen-Redaktion
    Programmierung

    Bevor Sie Änderungen committen, sollten Sie wissen, was Git gerade sieht: Welche Dateien sind neu, welche geändert, welche schon für den nächsten Commit vorgemerkt? Genau diese Momentaufnahme liefert git status. Nach diesem Artikel lesen Sie die Ausgabe sicher, kennen das schnelle Kurzformat, verstehen die Zeile zum Remote-Branch und wissen, warum Git manchmal scheinbar leere Ordner ignoriert.

    Der Befehl: git status

    Öffnen Sie ein Terminal, wechseln Sie in Ihr Repository und geben Sie ein:

    git status

    Git vergleicht dabei drei Zustände miteinander: das Arbeitsverzeichnis (Ihre Dateien auf der Festplatte), den Index bzw. Staging-Bereich (was beim nächsten git commit landet) und den letzten Commit (HEAD). Die Ausgabe fasst zusammen, wo diese drei auseinanderlaufen.

    Eine typische Ausgabe sieht so aus:

    On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   src/index.js

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:   README.md

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

    Die Ausgabe Abschnitt für Abschnitt

    Git gruppiert Dateien nach ihrem Zustand. Diese drei Kategorien sollten Sie sicher unterscheiden:

    • Changes to be committed – Änderungen liegen im Staging-Bereich. Sie wandern in den nächsten Commit. Mit git restore --staged <datei> nehmen Sie sie wieder heraus (in Git vor Version 2.23 lautete der Befehl git reset HEAD <datei>).
    • Changes not staged for commit – Die Datei ist versioniert und wurde geändert, die Änderung ist aber noch nicht gestaged. git add <datei> übernimmt sie, git restore <datei> verwirft sie.
    • Untracked files – Neue Dateien, die Git noch gar nicht verfolgt. Erst git add bringt sie unter Versionskontrolle. Steht eine Datei hier, die Sie dauerhaft ignorieren wollen, gehört sie in die .gitignore.

    Wichtig: Eine einzelne Datei kann gleichzeitig unter „Changes to be committed“ und „Changes not staged“ auftauchen. Das passiert, wenn Sie git add ausgeführt und die Datei danach erneut bearbeitet haben – der gestagte Stand und der aktuelle Stand unterscheiden sich dann.

    Die Branch-Zeile richtig deuten

    Die ersten Zeilen betreffen den Vergleich mit dem Remote-Repository:

    • Your branch is up to date with 'origin/main'. – lokaler und entfernter Stand sind identisch (Stand des letzten git fetch).
    • Your branch is ahead of 'origin/main' by 1 commit. – Sie haben lokale Commits, die noch nicht gepusht sind → git push.
    • Your branch is behind 'origin/main' by 2 commits. – auf dem Remote liegen neuere Commits; holen Sie sie mit git pull.
    • have diverged – beide Seiten sind vorangeschritten; hier ist ein bewusster git pull (Merge oder Rebase) nötig.

    Beachten Sie: git status fragt den Server nicht live ab. Verglichen wird gegen den lokal zwischengespeicherten Stand origin/main. Wollen Sie wissen, ob es serverseitig etwas Neues gibt, führen Sie zuerst git fetch aus und dann erneut git status.

    Kurzformat für den schnellen Blick

    Für den Alltag ist die ausführliche Ausgabe oft zu lang. Das Kurzformat passt in wenige Zeilen:

    git status -s

    -s steht für --short. Die Ausgabe nutzt zwei Spalten pro Datei – die linke steht für den Index (Staging), die rechte für das Arbeitsverzeichnis:

     M README.md
M  src/index.js
MM package.json
?? notes.txt

    So lesen Sie die Zeichen:

    • M = modified, A = added (neu gestaget), D = deleted, R = renamed, ?? = untracked.
    • Linke Spalte gesetzt → die Änderung ist gestaged. Rechte Spalte gesetzt → sie ist noch nicht gestaged.
    • M (Leerzeichen + M): geändert, nicht gestaged. M : gestaged. MM: gestaged und danach erneut geändert.

    Mit git status -sb bekommen Sie zusätzlich die Branch-Zeile im Kompaktformat, etwa ## main...origin/main [ahead 1].

    Nützliche Optionen

    • git status -uall (oder --untracked-files=all) zeigt jede einzelne untracked Datei statt nur den Ordnernamen. Standardmäßig fasst Git einen komplett neuen Ordner zu einer Zeile zusammen.
    • git status --ignored listet zusätzlich die von .gitignore ausgeschlossenen Dateien – praktisch, wenn Sie prüfen wollen, ob eine Datei absichtlich ignoriert wird.
    • git status --porcelain liefert ein stabiles, maschinenlesbares Format. Nutzen Sie es in Skripten und Hooks, denn die normale Ausgabe kann sich zwischen Git-Versionen und je nach Sprache ändern.

    Ein Beispiel für den Skript-Einsatz: Prüfen, ob das Arbeitsverzeichnis sauber ist, bevor ein Deploy startet:

    if [ -n "$(git status --porcelain)" ]; then
  echo "Arbeitsverzeichnis nicht sauber – bitte committen oder stashen."
  exit 1
fi

    Gibt git status --porcelain nichts aus, ist alles committet und der Baum sauber.

    Typische Stolperfallen

    „fatal: not a git repository“ – Sie befinden sich nicht in einem Git-Verzeichnis. Prüfen Sie Ihren Pfad mit pwd (Git Bash oder PowerShell) bzw. cd ohne Argument (Windows-Eingabeaufforderung) und wechseln Sie in den richtigen Ordner – oder initialisieren Sie mit git init ein neues Repository.

    Ein leerer Ordner taucht nicht auf – Git versioniert keine Verzeichnisse, nur Dateien. Ein leerer Ordner erscheint deshalb nie im Status. Üblicher Trick: eine Platzhalterdatei wie .gitkeep hineinlegen.

    Eine Datei fehlt im Status, obwohl Sie sie geändert haben – Vermutlich greift eine Regel aus der .gitignore. Mit git status --ignored oder git check-ignore -v <datei> finden Sie heraus, welche Regel zuständig ist.

    Umbenannte Datei erscheint als „deleted“ + „untracked“ – Solange die Umbenennung noch nicht gestaged ist, erkennt Git sie nicht als Rename. Nach git add fasst der Status beides als renamed: zusammen.

    Nur Groß-/Kleinschreibung geändert (macOS/Windows) – Diese Dateisysteme unterscheiden Groß- und Kleinschreibung standardmäßig nicht, deshalb übersieht Git die Änderung leicht. In solchen Fällen hilft git mv mit einem Zwischennamen.

    Git-Status in grafischen Tools

    Wer lieber visuell arbeitet, findet dieselben Informationen in GUI-Werkzeugen wie GitHub Desktop, Sourcetree, GitKraken oder der Git-Integration von VS Code. Sie zeigen gestagte und ungestagte Änderungen nebeneinander und heben Zeilen-Diffs farblich hervor. Für ein grundlegendes Verständnis lohnt es sich trotzdem, die Terminal-Ausgabe lesen zu können – Fehlermeldungen in CI-Systemen und auf Servern erscheinen fast immer in dieser Form. Wenn Sie mit Git gerade erst anfangen, ordnet der Überblick Wofür wird Git SCM verwendet? die einzelnen Befehle in den größeren Zusammenhang ein.

    FAQ

    Fragt git status den Server ab? Nein. Der Befehl arbeitet vollständig lokal und vergleicht gegen den zuletzt geholten Remote-Stand. Für aktuelle Server-Informationen führen Sie vorher git fetch aus.

    Was bedeutet „nothing to commit, working tree clean“? Arbeitsverzeichnis, Index und letzter Commit sind identisch. Es gibt keine offenen Änderungen, nichts ist zu stagen oder zu committen.

    Wie sehe ich nicht nur, welche Dateien, sondern auch was sich geändert hat? git status nennt nur die betroffenen Dateien. Die konkreten Zeilenänderungen zeigt git diff (ungestaget) bzw. git diff --staged (für den nächsten Commit vorgemerkt).