Git-Protokoll für Fortgeschrittene

Hierdurch erfährst du, dass der oberste Commit ausgecheckt ist (indiziert durch HEAD) und dass er sich an der Spitze des main-Branch befindet. Der zweite Commit hat einen anderen Branch namens feature, der auf ihn verweist, und der vierte Commit ist mit v0.9 getaggt.

Branches, Tags, HEAD und der Commit-Verlauf machen nahezu alle Informationen in deinem Git-Repository aus. Darüber kannst du einen umfassenderen Einblick in den logischen Aufbau deines Repositorys erhalten.

Der Befehl git log umfasst viele Optionen für die Anzeige von Diffs für jeden Commit. Zwei der gebräuchlichsten Optionen sind --stat und -p.

Mit der Option --stat werden die Anzahl von Einfügungen und Löschungen für jede einzelne Datei, die bei dem jeweiligen Commit geändert werden, angezeigt. (Beachte, dass die Bearbeitung einer Zeile als eine Einfügung und eine Löschung gezählt wird.) Dies ist hilfreich, wenn du eine kurze Zusammenfassung der Änderungen benötigst, die mit jedem Commit hinzukamen. Im folgenden Commit wurden z. B. 67 Zeilen zur Datei hello.py hinzugefügt und 38 Zeilen entfernt.

Die Anzahl an Zeichen (+ und -) neben dem Dateinamen zeigt dir die relative Anzahl der Änderungen an, die mit einem Commit an einer Datei vorgenommen wurden. Das kann ein Hinweis darauf sein, wo die Änderungen eines Commits zu finden sind.

Wenn du die tatsächlichen Änderungen sehen möchtest, die mit jedem einzelnen Commit hinzukamen, kannst du die Option -p an git log anfügen. Dies gibt den gesamten Patch, der diesen Commit repräsentiert, zurück:

Der Befehl git shortlog ist eine Spezialversion von git log zum Erstellen von Release-Ankündigungen. Es gruppiert alle Commits nach Autoren und zeigt die erste Zeile einer jeden Commit-Nachricht an. So kannst du bequem sehen, wer woran gearbeitet hat.

Wenn z. B. zwei Entwickler fünf Commits zu einem Projekt beigesteuert haben, könnte die Ausgabe vn git shortlog in etwa so aussehen:

Standardmäßig sortiert git shortlog den Output nach Name des Autors. Mit der Option -n kannst du aber auch nach Anzahl der Commits pro Autor sortieren.

Mit der Option --graph wird eine ASCII-Grafik zur Branch-Struktur des Commit-Verlaufs erstellt. Das wird oft zusammen mit den Befehlen --oneline und --decorate genutzt, um besser zu erkennen, welcher Commit zu welchem Branch gehört:

Bei einem einfachen Repository mit nur zwei Branches ergibt sich hierdurch Folgendes:

Das Sternsymbol zeigt, in welchem Branch sich der Commit befand. Dem obigen Graphen entnehmen wir also, dass die Commits 23ad9ad und 16b36c6 sich auf einem Themen-Branch und die übrigen Commits sich auf dem main-Branch befinden.

Für einfache Repositorys ist das zwar eine nette Option, doch bei Projekten mit sehr vielen Branches ist ein Virtualisierungstool mit großem Funktionsumfang wie gitk oder SourceTree vermutlich die bessere Wahl.

Für alle anderen git log-Formatierungen gibt es die Option --pretty=format:"". Damit kannst du die Anzeige einzelner Commits individuell definieren. Wir empfehlen jedoch Platzhalter im printf-Stil.

Die Zeichen %cn, %h und %cd werden im folgenden Befehl z. B. jeweils mit dem Committer-Namen, dem abgekürzten Commit-Hash und dem Commit-Durchführungsdatum ersetzt.

Hieraus ergibt sich das folgende Format für die einzelnen Commits:

Eine vollständige Liste der Platzhalter findest du auf der git log-Anleitungsseite im Abschnitt zu schönen Formaten.

Abgesehen davon, dass dir nur die Informationen angezeigt werden, die dich interessieren, ist die Option --pretty=format:"" besonders hilfreich, wenn du die Ausgabe von git log mit einem anderen Befehl kombinierst.

Wenn du weißt, wie du die Commit-Anzeige formatieren kannst, hast du schon die Hälfte aller Vorteile von git log kennengelernt. Wenn du auch weißt, wie du durch den Commit-Verlauf navigieren kannst, hast du aus dem Befehl alles herausgekitzelt. Im Folgenden zeigen wir einige erweiterte Methoden, um mit git log bestimmte Commits in deinem Projektverlauf zu finden. Diese Möglichkeiten kannst du mit allen bereits vorgestellten Formatierungsoptionen kombinieren.

Wenn du nach einem Commit von einem bestimmten Zeitrahmen suchst, kannst du die Zusätze --after oder --before verwenden, um die Commits nach Datum zu filtern. Beide akzeptieren verschiedene Datumsformate als Parameter. Mit dem folgenden Befehl werden beispielsweise nur Commits angezeigt, die nach (inklusive) dem 1. Juli 2014 erstellt wurden.

Du kannst auch relative Referenzen wie "1 week ago" und "yesterday" anfügen:

Um nach Commits zu suchen, die in einem bestimmten Zeitraum erstellt wurden, kannst du jeweils ein Datum --before (vor) und --after (nach) dem Zeitraum angeben. Wenn du beispielsweise alle Commits anzeigen möchtest, die zwischen dem 1. Juli 2014 und dem 4. Juli 2014 hinzugefügt wurden, gibst du Folgendes ein:

Wenn du nach Commits suchst, die von einem bestimmten Benutzer erstellt wurden, kannst du die Kennzeichnung --author verwenden. Mithilfe eines regulären Ausdrucks werden alle Commits angezeigt, deren Autor diesem Muster entspricht. Falls du genau weißt, nach wem du suchst, kannst du statt eines regulären Ausdrucks auch einen ganz einfachen String verwenden.

Hiermit werden alle Commits angezeigt, die den Autorennamen John enthalten. Der Autorenname muss nicht genau übereinstimmen, er muss nur den angegebenen Ausdruck enthalten.

Mit regulären Ausdrücken kannst du eine komplexere Suche durchführen. Zum Beispiel wird mit folgendem Befehl nach Commits gesucht, die entweder von Mary oder von John stammen.

Zusätzlich zum Autorennamen ist auch dessen E-Mail-Adresse enthalten, sodass du bei dieser Option auch nach E-Mail-Adressen suchen kannst.

Wenn in deinem Workflow Committer von Autoren getrennt werden, funktioniert die Option --committer auf dieselbe Weise.

Zum Filtern nach einer Commit-Nachricht bietet sich die Option --grep an. Sie funktioniert wie die oben besprochene Option --author, sucht aber Übereinstimmungen mit der Commit-Nachricht statt mit dem Autorennamen.

Wenn dein Team beispielsweise in jeder Commit-Nachricht relevante Issue-Nummern angibt, kannst du mit einem Befehl folgender Art alle Commits im Zusammenhang mit diesem Issue herausfiltern:

Außerdem kannst du den Parameter -i auf git log anwenden, um Unterschiede in der Groß- und Kleinschreibung beim Abgleich der Muster zu ignorieren.

Oftmals sind nur die Änderungen an einer spezifischen Datei von Interesse. Um einen dateibezogenen Verlauf anzuzeigen, musst du nur den Dateipfad angeben. Wenn du alle Commits anzeigen möchtest, die entweder foo.py oder bar.py tangieren, gibst du den folgenden Befehl ein:

Der Parameter -- teilt git log mit, dass die nachfolgenden Argumente Dateipfade und keine Branch-Namen sind. Falls keine Gefahr besteht, diese zu vermischen, kann -- auch weggelassen werden.

Es ist auch möglich, nach Commits zu suchen, die eine bestimmte Zeile Quellcode einführen oder entfernen. Diese Funktion wird Pickaxe genannt und hat die Form -S"". Wenn du z. B. wissen möchtest, wann der String Hallo Welt! zu Dateien des Projekts hinzugefügt wurde, fragst du dies folgendermaßen ab:

Um die Suche mithilfe eines regulären Ausdrucks statt mit einem String durchzuführen, kannst du stattdessen -G"" verwenden.

Das ist ein sehr leistungsstarkes Debugging-Tool, da du auf diese Weise alle Commits lokalisieren kannst, die eine bestimmte Codezeile betreffen. Du kannst dir sogar anzeigen lassen, wann eine Zeile kopiert oder in eine andere Datei verschoben wurde.

Du kannst git log mit einem Bereich kombinieren, sodass nur dir Commits, die in diesen Bereich fallen, angezeigt werden. Der Bereich wird mit und als Commit-Referenzen spezifiziert:

Dieser Befehl ist besonders wertvoll, wenn wir Branch-Referenzen als Parameter verwenden. So lassen sich die Unterschiede zwischen zwei Branches mühelos abzurufen. Nehmen wir den folgenden Befehl:

Der Bereich main..feature enthält alle Commits, die im feature-Branch, aber nicht im main-Branch enthalten sind. Anders gesagt: Hier sehen wir, wie weit sich der feature-Branch entwickelt hat, seit er vom main-Branch abgezweigt wurde. Dies kann folgendermaßen visuell dargestellt werden:

Hinweis: Wenn du die Reihenfolge umkehrst (feature..main), werden dir alle Commits angezeigt, die sich im main-Branch, aber nicht im feature-Branch befinden. Wenn git log Commits für beide Versionen ausgibt, weißt du, dass der Verlauf voneinander abweicht.

Standardmäßig enthält git log Merge Commits in der Ausgabe. Manche Teams verfolgen jedoch eine Always-merge-Strategie: Sie mergen Upstream-Änderungen in Themen-Branches, statt den Themen-Branch auf den Upstream-Branch zu rebasen. Das resultiert in einer großen Menge an Merge-Commits im Projektverlauf.

Wenn du nicht möchtest, dass git log diese Merge-Commits anzeigt, kannst du --no-merges verwenden:

Wenn du aber nur an den Merge-Commits interessiert bist, kannst du --merges verwenden:

Hiermit werden alle Commits ausgegeben, für die mindestens zwei Parents vorhanden sind.

Nun solltest du in der Lage sein, die erweiterten git log-Parameter zur Formatierung der Ausgabe und Auswahl der anzuzeigenden Commits zu verwenden. Du kannst also genau die Informationen aus deinem Projektverlauf entnehmen, die du benötigst.

Diese Fähigkeit ist ein wichtiger Bestandteil im Git-Toolkit, aber git log wird häufig auch in Verbindung mit anderen Befehlen genutzt. Nachdem du den gewünschten Commit gefunden hast, wirst du ihn höchstwahrscheinlich mit git checkout, git revert oder einem anderen Tool weiter manipulieren. Deshalb solltest du dich unbedingt auch in die erweiterten Features von Git einlesen.