Der Zweck eines jeden Versionskontrollsystems besteht darin, Änderungen an unserem Code festzuhalten. Das gibt uns die Macht, in unserer Projekthistorie zurückzugehen und zu sehen, wer was beigesteuert hat, herauszufinden, wo Bugs eingeführt wurden, und problematische Änderungen rückgängig zu machen. Aber all diese Historie verfügbar zu haben, bringt uns nichts, solange wir nicht wissen, wie wir in ihr navigieren. An dieser Stelle kommt der Befehl git log ins Spiel.
Wir sollten inzwischen mit den grundlegenden git log-Kommandos zum Anzeigen von Commits vertraut sein, siehe das Basis-Tutorial. Aber wir können diesen Output dadurch anpassen, dass wir git log mit vielen verschiedenen Parametern verwenden.
Die erweiterten Funktionen von git log lassen sich in zwei Kategorien einteilen: die Formatierung, wie ein jeder Commit angezeigt wird, und die Filterung, welche Commits in der Ausgabe enthalten sind. Zusammen geben uns diese beiden Optionen die Möglichkeit, in unserem Projekt zurückzugehen und jede Information zu finden, die wir brauchen.
Log-Output formatieren
Zunächst wollen wir einen Blick auf die vielen Wege werfen, den Output von git log zu formatieren. Die meisten Optionen werden in Form sogenannter Flags genutzt, um mehr oder weniger Informationen abzufragen.
Wer das voreingestellte Format von git log nicht mag, kann übrigens mit der Aliasing-Funktion von git config Shortcuts für alle nachfolgend diskutierten Formatierungsoptionen erstellen.
Oneline
Der Zusatz --oneline verdichtet jeden Commit auf eine einzelne Zeile. Im Standard werden die Commit-ID und die erste Zeile der Commit-Nachricht angezeigt. Ein typischer Output von git log --oneline wird in etwa so aussehen:
0e25143 Merge branch 'feature' ad8621a Fix a bug in the feature 16b36c6 Add a new feature 23ad9ad Add the initial code base
Das ist sehr hilfreich, um sich einen grundsätzlichen Überblick über das Projekt zu verschaffen.
Decorate
Oft ist es sinnvoll zu wissen, welche Branches oder Tags mit Commits assoziiert sind. Die Option --decorate weist Git an, alle Referenzen (also Branches, Tags usw.) anzuzeigen, die auf jeden Commit verweisen.
Dies können wir mit anderen Konfigurationsoptionen kombinieren. Der Befehl git log --oneline --decorate formatiert die Commit-Historie beispielsweise so:
0e25143 (HEAD, master) Merge branch 'feature' ad8621a (feature) Fix a bug in the feature 16b36c6 Add a new feature 23ad9ad (tag: v0.9) Add the initial code base
Damit erfahren wir, dass der oberste Commit zudem ausgecheckt ist (indiziert durch HEAD) und dass er sich an der Spitze des master-Branchs 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, der HEAD-Status und die Commit-Historie sind fast alle Informationen, die in unserem Git-Repository enthalten sind. Somit erhalten wir einen recht vollständigen Blick auf die logische Struktur unseres Repos.
Diffs
Der Befehl git log umfasst auch diverse Optionen, um mit jedem Commit die Diffs anzuzeigen. Zwei der am häufigsten gebrauchten Optionen sind --stat und -p.
--stat zeigt die Anzahl der Einfügungen und Löschungen für jede Datei an, die durch einen Commit geändert wurde. Das ist nützlich, wenn wir eine kurze Zusammenfassung der Änderungen haben möchten, die mit einem Commit einhergegangen sind. Beispielsweise hat der folgende Commit der Datei hello.py 67 Zeilen hinzugefügt und 38 Zeilen aus ihr entfernt:
commit f2a238924e89ca1d4947662928218a06d39068c3
Author: John <john@example.com>
Date: Fri Jun 25 17:30:28 2014 -0500
Add a new feature
hello.py | 105 ++++++++++++++++++++++++-----------------
1 file changed, 67 insertion(+), 38 deletions(-)
Die Zeichen + und - neben dem Dateinamen indizieren die relative Anzahl der Änderungen an jeder Datei an, die durch den Commit modifiziert wurde. So erhalten wir eine Ahnung davon, wo wir die Änderungen für jeden Commit finden können.
Wenn wir die tatsächlichen Änderungen einsehen möchten, die durch Commits eingeführt worden sind, können wir die Option -p mit git log verwenden. Dadurch erhalten wir die folgende umfassende Übersicht, die diesen Commit repräsentiert:
commit 16b36c697eb2d24302f89aa22d9170dfe609855b
Author: Mary <mary@example.com>
Date: Fri Jun 25 17:31:57 2014 -0500
Fix a bug in the feature
diff --git a/hello.py b/hello.py
index 18ca709..c673b40 100644
--- a/hello.py
+++ b/hello.py
@@ -13,14 +13,14 @@ B
-print("Hello, World!")
+print("Hello, Git!")
Bei Commits mit vielen Änderungen kann die Ausgabe entsprechend lang und unhandlich werden. Wenn wir einen Commit so ausführlich anzeigen, suchen wir wahrscheinlich nach einer ganz bestimmten Änderung. Dafür ist die Pickaxe-Option nützlich. Auf sie kommen wir später noch zu sprechen.
Im nachfolgenden zweiten Teil dieses Tutorials werden wir uns weitere Formatierungsmöglichkeiten von git log ansehen.
Git und Bitbucket Server effektiv nutzen? Wir sind Ihr Partner!
Kennen Sie Bitbucket Server (vormals Stash), Atlassians Git-Repository-Managementsystem? Bitbucket Server bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben. Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Bitbucket Server.
Übrigens: //SEIBERT/MEDIA bietet auch professionelle Grundlagen- und Aufbau-Workshops zu Git und Bitbucket Server an.
Weiterführende Infos
99 Argumente für Bitbucket Server (Stash) als Git-Repository-Manager
Branch-basierte Git-Workflows adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
Interview: Die Vorteile von Git in der Software-Entwicklung und die Möglichkeiten von Bitbucket Server (Stash)
So funktioniert die Lizenzierung von Atlassian-Produkten
