Einführung
Kurzbeschreibung der Befehle git status, git log, git tag und git blame sowie deren grundlegende Verwendung und häufige Anwendungsfälle.
Sobald Sie ein Git-Repository mit etwas Verlauf besitzen, dreht sich der Großteil Ihrer täglichen Arbeit nicht um das Ändern von Dateien – sondern darum, deren aktuellen und vergangenen Zustand zu verstehen. Bevor Sie etwas committen, pushen oder rückgängig machen, möchten Sie gewöhnlich Fragen beantworten wie: Was habe ich geändert, aber noch nicht gespeichert? Wer hat diese Zeile geschrieben, und warum? Wann wurde dieser Fehler eingeführt? Zu welchem Release gehört dieser Commit?
Dieser Teil des Tutorials behandelt die vier Befehle, die Sie am häufigsten verwenden, wenn Sie ein Repository untersuchen statt es zu verändern:
| Befehl | Was er beantwortet | Bereich |
|---|---|---|
git status | Was hat sich seit dem letzten Commit geändert, und was ist bereits staged? | Arbeitsverzeichnis + Staging-Area |
git log | Wie sieht die Commit-Historie aus? | Nur committete Snapshots |
git tag | Welche Commits sind bedeutsam (z. B. Releases)? | Benannte Zeiger auf Commits |
git blame | Wer hat jede Zeile zuletzt geändert, und in welchem Commit? | Zeilenweise Autorenschaft einer Datei |
Jeder Befehl wird unten mit einem kurzen Beispiel zusammengefasst. Die folgenden Seiten behandeln alle Optionen im Detail.
git status
Der Befehl git status zeigt den Zustand des Arbeitsverzeichnisses und der Staging-Area an. Er lässt Sie erkennen, welche Änderungen für den nächsten Commit vorgemerkt sind und welche Dateien von Git noch nicht verfolgt werden. Er zeigt keine committete Historie – nur die Differenz zwischen Ihren aktuellen Dateien und dem letzten Commit.
Führen Sie ihn innerhalb eines beliebigen Repositorys aus:
$ git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: index.html
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
modified: style.css
Untracked files:
(use "git add <file>..." to include in what will be committed)
notes.txtHier ist index.html staged (sie wird in den nächsten Commit aufgenommen), style.css wurde geändert, aber noch nicht staged, und notes.txt ist ganz neu und wird nicht verfolgt. Machen Sie git status zur Gewohnheit vor jedem Commit, damit Sie nie versehentlich eine Datei committen – oder vergessen.
git log
Der Befehl git log untersucht die committete Historie eines Repositorys und hilft Ihnen, eine bestimmte Version eines Projekts zu finden. Er listet, filtert und durchsucht Commits – arbeitet aber ausschließlich mit der committeten Historie, sodass noch nicht committete Änderungen nicht erscheinen.
$ git log --oneline -3
9a3c1f4 (HEAD -> main) Fix navbar alignment on mobile
1d72b08 Add contact form validation
f0e5a91 Initial commitDas Flag --oneline verdichtet jeden Commit auf seinen kurzen Hash und den Betreff. Sie können nach Autor (--author), nach Datum (--since, --until) oder nach Inhalt (-S "searchterm") filtern, um genau zu ermitteln, wann eine Änderung vorgenommen wurde. Um einen einzelnen Commit vollständig zu inspizieren, kombinieren Sie git log mit git show.
git tag
Tags sind Referenzen, die auf bestimmte, bedeutsame Punkte in der Git-Historie zeigen. Ihr Hauptzweck ist es, einen Release zu markieren – zum Beispiel v1.0.0. Anders als ein Branch bewegt sich ein Tag nicht, wenn Sie neue Commits hinzufügen; einmal erstellt, zeigt er dauerhaft auf denselben Snapshot.
$ git tag v1.0.0 # create a lightweight tag on the current commit
$ git tag # list existing tags
v1.0.0
$ git tag -a v1.1.0 -m "Release 1.1.0" # create an annotated tag with a messageEin Lightweight-Tag ist lediglich ein Name für einen Commit, während ein annotierter Tag (-a) zusätzlich den Ersteller, ein Datum und eine Nachricht speichert – annotierte Tags werden für Releases empfohlen. Tags werden nicht automatisch gepusht; Sie teilen sie mit git push origin v1.0.0 (oder git push --tags).
git blame
Der Befehl git blame zeigt die Autoren-Metadaten für jede Zeile einer Datei: den Commit, den Autor und das Datum, an dem die Zeile zuletzt geändert wurde. Er ist das erste Werkzeug, um zu verstehen, warum eine bestimmte Zeile existiert und wen man dazu befragen kann.
$ git blame -L 1,3 index.html
9a3c1f4a (Jane Doe 2024-03-12 10:22:01 +0000 1) <!DOCTYPE html>
1d72b08c (John Roe 2024-02-28 14:05:33 +0000 2) <html lang="en">
9a3c1f4a (Jane Doe 2024-03-12 10:22:01 +0000 3) <head>Das Flag -L 1,3 begrenzt die Ausgabe auf die Zeilen 1–3. Jede Zeile ist mit dem kurzen Commit-Hash, dem Autor und dem Zeitstempel der letzten Änderung versehen. Um einen dieser Commits genauer zu untersuchen, kopieren Sie seinen Hash in git show oder git log.
Untersuchen vs. Ändern
Ein nützliches mentales Modell: Diese Befehle sind schreibgeschützt. Keiner der Befehle git status, git log, git tag (beim Auflisten) oder git blame verändert Ihre Dateien oder Historie – sie geben nur den Zustand aus. Das macht es sicher, sie jederzeit auszuführen. Wenn Sie tatsächlich etwas am Aufgezeichneten ändern möchten, greifen Sie zu anderen Werkzeugen wie git commit, git checkout oder git diff, um Änderungen zuerst in der Vorschau zu betrachten.