Übersicht

git blame [-L <range>] [-w] [-M] [-C] <file>

Beschreibung

Der git blame-Befehl annotiert jede Zeile einer Datei mit dem Commit, dem Autor und dem Zeitstempel, die sie zuletzt berührt haben. Er ist unschätzbar, um zu verstehen, warum ein Stück Code so aussieht, wie es aussieht, wer es eingeführt hat und wann. Trotz des anschuldigenden Namens wird Blame meist als Recherchewerkzeug verwendet, nicht als Mittel zum Schuldzuweisen.

Blame kann Code folgen, wenn er verschoben oder kopiert wurde (mit -M und -C), und kann Whitespace-only- oder reine Formatierungs-Commits ignorieren, wenn Sie eine .git-blame-ignore-revs-Datei pflegen, die über blame.ignoreRevsFile referenziert wird.

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

Häufige Optionen

Option	Beschreibung
-L <start>,<end>	Beschränkt Blame auf einen Zeilenbereich.
-w	Ignoriert Whitespace-Änderungen.
-M	Erkennt innerhalb einer Datei verschobene Zeilen.
-C	Erkennt aus anderen Dateien kopierte Zeilen (wiederholen für stärkere Erkennung).
--since=<date>	Hört vor diesem Datum mit dem Annotieren auf.
-e, --show-email	Zeigt Autor-E-Mail statt Namen.
--ignore-revs-file <file>	Überspringt aufgeführte Revisionen beim Zuweisen von Blame.

Beispiele

git blame src/parser.c
    # Jede Zeile annotieren

    git blame -L 50,100 src/parser.c
    # Nur Zeilen 50 bis 100

    git blame -w -M -C README.md
    # Whitespace ignorieren und Verschiebungen/Kopien erkennen

    git blame --ignore-revs-file .git-blame-ignore-revs file.js
    # Lärmige Formatierungs-Commits überspringen

Häufige Fehler

Blame zu nutzen, um Schuld zuzuweisen statt Kontext zu untersuchen, schafft eine feindselige Kultur. Paaren Sie Blame mit git log auf dem fraglichen Commit, um die vollständige Nachricht und Absicht zu lesen. Nach einer Massenformatierung richten Sie .git-blame-ignore-revs ein, sodass Blame weiterhin auf bedeutsame Autoren zeigt.

Verwandte Befehle

git log -L, git log -S, git show, git annotate