Der Befehl git log dient unter anderem dazu, ein Projekt nach spezifischen Commits zu filtern und genau diejenigen aufzufinden, die uns interessieren. Im vorangehenden Teil dieses Tutorials haben wir einige Filtermöglichkeiten kennengelernt. Nun diskutieren wir weitere.

Nach Dateien

Oftmals sind wir nur an Änderungen an einer spezifischen Datei interessiert. Um eine dateibezogene Historie anzuzeigen, müssen wir nur den Dateipfad angeben. Um alle Commits anzuzeigen, die entweder foo.py oder bar.py tangieren, nutzen wir dieses Kommando:

git log -- foo.py bar.py

Der Parameter -- sagt Git, dass die nachfolgenden Argumente Dateipfade und keine Branch-Namen sind. Falls keine Gefahr besteht, diese zu vermengen, können wir -- auch weglassen.

Nach Inhalt

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"<string>". Wenn wir wissen möchten, wann der String Hello, World! zu irgendwelchen Dateien unseres Projekts hinzugefügt wurde, fragen wir dies so ab:

git log -S"Hello, World!"

Um die Suche mithilfe eines regulären Ausdrucks statt mit einem String durchzuführen, können wir stattdessen die Option -G"<regex>" nutzen.

Das ist ein sehr mächtiges Debugging-Werkzeug, denn wir können alle Commits lokalisieren, die eine bestimmte Codezeile betreffen. Wir können uns sogar anzeigen lassen, wann eine Zeile kopiert oder in eine andere Datei bewegt wurde.

Nach Bereich

Desweiteren haben wir die Möglichkeit, nach einem Bereich von Commits zu suchen und nur diejenigen Commits anzuzeigen, die in diesem Bereich enthalten sind. Den Bereich spezifizieren wir mit <von> und <bis> als Commit-Referenzen:

git log <von>..<bis>

Dieser Befehl ist besonders wertvoll, wenn wir Branch-Referenzen als Parameter verwenden. So haben wir eine einfache Möglichkeit, um die Unterschiede zwischen zwei Branches abzurufen. Nehmen wir den folgenden Befehl:

git log master..feature

Der Bereich master..feature enthält alle Commits, die im feature-Branch, aber nicht im master-Branch enthalten sind. Anders gesagt: Hier sehen wir, wie weit der feature-Branch sich entwickelt hat, seit er vom master abgezweigt wurde.

Hinweis: Wenn wir die Reihenfolge umkehren (feature..master), sehen wir alle Commits, die im master-Branch, aber nicht im feature-Branch sind. Wenn git log Commits für beide Versionen ausgibt, wissen wir, dass unsere Historie divergiert ist.

Merge-Commits filtern

Per Voreinstellung inkludiert git log Merge-Commits in die Ausgabe. Manche Teams verfolgen jedoch eine Always-merge-Strategie: Sie mergen Upstream-Änderungen in Topic-Branches, statt den Topic-Branch auf den Upstream-Branch zu rebasen. Das resultiert in einer großen Menge an Merge-Commits in der Projekthistorie.

Wenn wir nicht wollen, dass git log diese Merge-Commits anzeigt, können wir die Option --no-merges nutzen:

git log --no-merges

Interessieren wir uns andererseits nur für die Merge-Commits, verwenden wir die Option --merges:

git log --merges

So erhalten wir alle Commits, die mindestens zwei Eltern haben.

Zusammenfassung

Mit diesem Wissen aus dieser Tutorial-Reihe (siehe auch Teil 1, 2 und 3) sollten wir in der Lage sein, die erweiterten git log-Parameter effektiv für uns zu nutzen, um die Ausgabe zu formatieren und anzuzeigende Commits zu selektieren. Dies befähigt uns, exakt die Infos aus einer Projekthistorie zu ziehen, die wir benötigen.

Es handelt sich um einen wichtigen Bestandteil des Git-Werkzeugkastens, aber vergessen wir nicht, dass git log oft in Verbindung mit anderen Git-Befehlen genutzt wird. Wenn wir den gewünschten Commit gefunden haben, werden wir ihn in aller Regel mit git checkout, git revert oder einem anderen Werkzeug weiter manipulieren. Es lohnt sich gewiss, sich auch in die effektive Nutzung dieser Kommandos tiefer einzulesen. Hier ist eine Übersicht unserer Inhalte und Anleitungen zu Git.

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