Übersicht

git log [<options>] [<revision-range>] [[--] <path>...]

Beschreibung

Der git log-Befehl zeigt die Commit-Historie, die von einer oder mehreren Refs aus erreichbar ist (Standard ist HEAD). Er ist eines der flexibelsten Werkzeuge in Git und unterstützt das Filtern nach Autor, Datum, Nachrichteninhalt, Dateipfaden und mehr. Kombiniert mit Formatierungsoptionen kann er Ausgaben erzeugen, die für Changelogs, Audits und Code-Archäologie geeignet sind.

Nützliche Idiome sind git log --oneline --graph --decorate --all für eine kompakte, visuelle Ansicht der gesamten Historie und git log -p, um Patches inline zu sehen. Pathspec-Argumente beschränken das Log auf Commits, die bestimmte Dateien berührt haben.

Im täglichen Einsatz integriert sich git log 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 log --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 log 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 log hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
--oneline	Ein Commit pro Zeile, abgekürzter SHA + Betreff.
--graph	ASCII-Art der Branch- und Merge-Struktur.
--all	Bezieht alle Refs ein, nicht nur HEAD.
-p, --patch	Zeigt Diffs zu jedem Commit.
--stat	Zeigt Statistiken zu geänderten Dateien.
--author=<pattern>	Filtert nach Autor.
--since / --until	Filtert nach Datum.
-S <string>	Pickaxe: findet Commits, die diesen String hinzufügen/entfernen.
--follow	Verfolgt die Historie einer einzelnen Datei über Umbenennungen hinweg.

Beispiele

git log --oneline --graph --decorate --all
    # Kompakte visuelle Historie von allem

    git log -p src/auth.py
    # Vollständige Diffs jedes Commits, der auth.py berührt

    git log -S "TODO" --since="2 weeks ago"
    # Jüngste Commits finden, die "TODO" hinzufügten oder entfernten

    git log --author="alice" --pretty=format:"%h %s" -n 20
    # Letzte 20 Commits von alice in eigenem Format

Häufige Fehler

Vergessen, dass git log file.txt nur Commits zeigt, in denen file.txt existierte — verwenden Sie --follow, falls sie umbenannt wurde. Übermäßiges Verlassen auf --grep, wenn Sie eigentlich -S wollen (das Diffs durchsucht, nicht Nachrichten). Und auf riesigen Repos kann git log -p ohne Pfad Gigabyte an Ausgabe erzeugen.

Verwandte Befehle

git show, git blame, git shortlog, git diff