7.10 Git Tools - Debuggen mit Git

Wenn Sie einen Fehler in Ihrem Code finden und wissen wollen, wann und warum er eingeführt wurde, ist die Datei-Annotation oft Ihr bestes Werkzeug. Es zeigt Ihnen, welcher Commit als letzter jede Zeile einer Datei geändert hat. Wenn Sie also sehen, dass eine Methode in Ihrem Code fehlerhaft ist, können Sie die Datei mit git blame annotieren, um festzustellen, welcher Commit für die Einführung dieser Zeile verantwortlich war.

Das folgende Beispiel verwendet git blame, um zu bestimmen, welcher Commit und Committer für die Zeilen im Makefile des Linux-Kernels der obersten Ebene verantwortlich war. Außerdem verwendet es die Option -L, um die Ausgabe der Annotation auf die Zeilen 69 bis 82 dieser Datei zu beschränken:

Beachten Sie, dass das erste Feld der partielle SHA-1 des Commits ist, der diese Zeile zuletzt geändert hat. Die nächsten beiden Felder sind Werte, die aus diesem Commit extrahiert wurden — der Name des Autors und das Datum dieses Commits — so dass Sie leicht sehen können, wer diese Zeile wann geändert hat. Danach folgen die Zeilennummer und der Inhalt der Datei. Beachten Sie auch die ^1da177e4c3f4 Commit-Zeilen, wobei das ^-Präfix Zeilen bezeichnet, die beim ersten Commit des Repositorys eingeführt wurden und seitdem unverändert geblieben sind. Das ist ein bisschen verwirrend, denn jetzt haben Sie mindestens drei verschiedene Möglichkeiten gesehen, wie Git das Zeichen ^ verwendet, um einen Commit SHA-1 zu modifizieren, aber das ist es, was es hier bedeutet.

Eine weitere coole Sache an Git ist, dass es Dateiumbenennungen nicht explizit verfolgt. Es zeichnet die Snapshots auf und versucht dann im Nachhinein herauszufinden, was implizit umbenannt wurde. Eines der interessanten Features ist, dass man Git bitten kann, auch alle Arten von Codebewegungen herauszufinden. Wenn Sie -C an git blame übergeben, analysiert Git die Datei, die Sie annotieren, und versucht herauszufinden, woher die Codeschnipsel darin ursprünglich kamen, wenn sie von woanders kopiert wurden. Nehmen wir an, Sie zerlegen eine Datei namens GITServerHandler.m in mehrere Dateien, von denen eine GITPackUpload.m ist. Indem Sie GITPackUpload.m mit git blame -C aufrufen, können Sie sehen, wo Abschnitte des Codes ursprünglich herkamen:

Das ist wirklich nützlich. Normalerweise erhalten Sie als Original-Commit den Commit, wo Sie den Code hinüber kopiert haben, denn das ist das erste Mal, dass Sie diese Zeilen in dieser Datei berührt haben. Mit der Option -C gibt Ihnen Git den ursprünglichen Commit, in dem Sie diese Zeilen geschrieben haben, auch wenn das in einer anderen Datei war.

Das Annotieren einer Datei hilft, wenn Sie wissen, wo das Problem liegt. Wenn Sie nicht wissen, was kaputt ist, und es gab Dutzende oder Hunderte von Commits seit dem letzten Zustand, von dem Sie wissen, dass der Code funktioniert hat, werden Sie sich wahrscheinlich an git bisect wenden, um Hilfe zu holen. Der Befehl bisect führt eine binäre Suche durch Ihre Commit-Historie durch, um Ihnen zu helfen, so schnell wie möglich zu identifizieren, welcher Commit ein Problem eingeführt hat.

Nehmen wir an, Sie haben gerade eine Version Ihres Codes in eine Produktionsumgebung ausgelagert, Sie erhalten Fehlerberichte über etwas, das nicht in Ihrer Entwicklungsumgebung passiert ist, und Sie können sich nicht vorstellen, warum der Code das tut. Sie gehen zurück zu Ihrem Code und es stellt sich heraus, dass Sie den Fehler reproduzieren können, aber Sie können nicht herausfinden, was schief läuft. Sie können den Code halbieren (engl. bisect), um es herauszufinden. Zuerst rufen Sie git bisect start auf, um die Dinge zum Laufen zu bringen. Dann benutzen Sie git bisect bad, um dem System mitzuteilen, dass der aktuelle Commit, auf dem Sie sind, nicht funktioniert. Dann müssen Sie git bisect sagen, wann der letzte bekannte gute (funktionierende) Zustand war, indem Sie git bisect good <good_commit> verwenden:

Git hat herausgefunden, dass etwa 12 Commits zwischen dem Commit, den Sie als letzten guten Commit (v1.0) markiert haben, und der aktuellen schlechten Version liegen, und ist für Sie zu dem mittleren Commit gewechselt (interner git checkout). An diesem Punkt können Sie Ihren Test durchführen, um zu sehen, ob der Fehler zum Zeitpunkt dieses Commits existiert. Wenn ja, dann wurde er irgendwann vor diesem mittleren Commit eingeführt; wenn nicht, dann wurde das Problem irgendwann nach dem mittleren Commit eingeführt. In diesem Beispiel stellt sich heraus, dass es hier kein Problem gibt, und Sie sagen Git das, indem Sie git bisect good tippen und Ihre Reise fortsetzen:

Jetzt sind Sie auf einem anderen Commit, auf halbem Weg zwischen dem, den Sie gerade getestet haben und Ihrem schlechten Commit. Sie führen Ihren Test noch einmal durch und stellen fest, dass dieser Commit fehlerhaft ist. Also sagen Sie Git das mit git bisect bad:

Dieser Commit ist in Ordnung, und jetzt hat Git alle Informationen, die es braucht, um festzustellen, wo das Problem eingeführt wurde. Es gibt Ihnen den SHA-1 des ersten fehlerhaften Commits und zeigt einige der Commit-Informationen und welche Dateien in diesem Commit verändert wurden, so dass Sie herausfinden können, was diesen Fehler eingeführt haben könnte:

Wenn Sie fertig sind, sollten Sie git bisect reset ausführen, um Ihren HEAD wieder auf den Stand vor dem Start zurückzusetzen (ansonsten landen Sie in einem seltsamen Zustand):

Dies ist ein mächtiges Werkzeug, das Ihnen helfen kann, hunderte von Commits in Minuten auf einen eingeführten Fehler zu überprüfen. Tatsächlich können Sie git bisect vollständig automatisieren, falls Sie ein Skript haben, das mit einer Ausgabe von 0 beendet, wenn das Projekt funktioniert und mit einer Ausgabe ungleich 0 beendet, wenn das Projekt nicht funktioniert. Zuerst teilen Sie Git wieder den Umfang der Bisektion mit, indem Sie die bekannten schlechten und guten Commits angeben. Sie können dies tun, indem Sie sie dem Befehl bisect start den bekannten schlechten Commit zuerst und den bekannten guten Commit als zweiten Parameter geben:

Dabei wird automatisch test-error.sh bei jedem ausgecheckten Commit ausgeführt, bis Git den ersten fehlerhaften Commit findet. Sie können auch etwas wie make or make tests oder was auch immer Sie haben, das automatische Tests für Sie ausführt, nutzen.