7.10 Git-Werkzeuge - Debugging mit Git

Wenn Sie einen Fehler in Ihrem Code finden und wissen möchten, wann und warum er eingeführt wurde, ist die Datei-Annotation oft Ihr bestes Werkzeug. Sie zeigt Ihnen, welcher Commit die letzte Änderung an jeder Zeile einer Datei vorgenommen hat. Wenn Sie also feststellen, 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 festzustellen, welcher Commit und welcher Committer für die Zeilen in der obersten Ebene des Linux-Kernel-Makefile verantwortlich war, und verwendet weiter 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 die partielle SHA-1-Signatur 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 der Autorenschaft dieses Commits –, sodass 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 Commit-Zeilen ^1da177e4c3f4, wobei das ^-Präfix Zeilen kennzeichnet, die im ersten Commit des Repositorys eingeführt wurden und seitdem unverändert geblieben sind. Das ist etwas verwirrend, da Sie nun mindestens drei verschiedene Arten gesehen haben, wie Git das ^ verwendet, um eine Commit-SHA-1-Signatur zu modifizieren, aber genau das bedeutet es hier.

Eine weitere coole Sache an Git ist, dass es keine expliziten Dateiumbenennungen verfolgt. Es speichert die Snapshots und versucht dann im Nachhinein implizit zu ermitteln, was umbenannt wurde. Eine interessante Funktion davon ist, dass Sie es bitten können, alle Arten von Codebewegungen zu ermitteln. Wenn Sie -C an git blame übergeben, analysiert Git die Datei, die Sie annotieren, und versucht herauszufinden, woher Codefragmente ursprünglich stammen, wenn sie von anderswo kopiert wurden. Sagen wir zum Beispiel, Sie refaktorieren eine Datei namens GITServerHandler.m in mehrere Dateien, eine davon ist GITPackUpload.m. Indem Sie GITPackUpload.m mit der Option -C „blamen“, können Sie sehen, woher Codeabschnitte ursprünglich stammen.

Das ist wirklich nützlich. Normalerweise erhalten Sie als ursprünglichen Commit den Commit, bei dem Sie den Code kopiert haben, da dies das erste Mal ist, dass Sie diese Zeilen in dieser Datei berührt haben. Git teilt Ihnen den ursprünglichen Commit mit, bei dem Sie diese Zeilen geschrieben haben, auch wenn sie in einer anderen Datei waren.

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

Nehmen wir an, Sie haben gerade eine Veröffentlichung Ihres Codes in einer Produktionsumgebung vorgenommen, erhalten Fehlerberichte über etwas, das in Ihrer Entwicklungsumgebung nicht auftrat, und Sie können sich nicht vorstellen, warum der Code das tut. Sie gehen zurück zu Ihrem Code und stellen fest, dass Sie das Problem reproduzieren können, aber nicht herausfinden können, was schiefgeht. Sie können den Code mit bisect untersuchen. Zuerst führen Sie git bisect start aus, um loszulegen, und dann verwenden Sie git bisect bad, um dem System mitzuteilen, dass der aktuelle Commit, auf dem Sie sich befinden, fehlerhaft ist. Dann müssen Sie Bisect mitteilen, wann der letzte bekannte gute Zustand war, indem Sie git bisect good <guter_commit> verwenden.

Git hat festgestellt, dass etwa 12 Commits zwischen dem Commit, den Sie als letzten guten Commit markiert haben (v1.0), und der aktuellen fehlerhaften Version liegen, und hat den mittleren für Sie ausgecheckt. An dieser Stelle können Sie Ihren Test ausführen, um zu sehen, ob das Problem bei diesem Commit besteht. Wenn ja, wurde es irgendwann vor diesem mittleren Commit eingeführt; wenn nicht, wurde das Problem irgendwann nach dem mittleren Commit eingeführt. Es stellt sich heraus, dass hier kein Problem vorliegt, und Sie teilen Git dies mit, indem Sie git bisect good eingeben und Ihre Reise fortsetzen.

Jetzt sind Sie bei einem anderen Commit, auf halbem Weg zwischen dem gerade getesteten und Ihrem fehlerhaften Commit. Sie führen Ihren Test erneut aus und stellen fest, dass dieser Commit fehlerhaft ist. Sie teilen Git dies mit git bisect bad mit.

Dieser Commit ist in Ordnung, und nun hat Git alle Informationen, die es benötigt, um festzustellen, wo das Problem eingeführt wurde. Es zeigt Ihnen die SHA-1-Signatur des ersten fehlerhaften Commits und einige Commit-Informationen sowie welche Dateien in diesem Commit geändert wurden, damit Sie herausfinden können, was passiert ist, das diesen Fehler eingeführt haben könnte.

Wenn Sie fertig sind, sollten Sie git bisect reset ausführen, um Ihren HEAD auf den Zustand zurückzusetzen, in dem Sie sich vor dem Start befanden, da Sie sonst in einem seltsamen Zustand landen.

Dies ist ein leistungsfähiges Werkzeug, das Ihnen helfen kann, Hunderte von Commits in wenigen Minuten auf einen eingeführten Fehler zu überprüfen. Tatsächlich können Sie git bisect vollständig automatisieren, wenn Sie ein Skript haben, das 0 zurückgibt, wenn das Projekt gut ist, oder einen Wert ungleich 0, wenn das Projekt fehlerhaft ist. Zuerst teilen Sie ihm erneut den Umfang des Bisecting mit, indem Sie die bekannten fehlerhaften und guten Commits angeben. Dies können Sie tun, indem Sie sie mit dem Befehl bisect start auflisten, wenn Sie möchten, wobei Sie den bekannten fehlerhaften Commit zuerst und den bekannten guten Commit als zweiten angeben.

Dadurch wird test-error.sh automatisch für jeden ausgecheckten Commit ausgeführt, bis Git den ersten fehlerhaften Commit gefunden hat. Sie können auch etwas wie make oder make tests oder was auch immer Sie haben, das automatisierte Tests für Sie ausführt, ausführen.