7.10 Git Tools - Debuggen mit Git

Wenn du einen Fehler in deinem Code findest und wissen willst, wann und warum er eingeführt wurde, ist die Datei-Annotation oft dein bestes Werkzeug. Es zeigt dir, welcher Commit als letzter jede Zeile einer Datei geändert hat. Wenn du also bemerkst, dass eine Methode in deinem Code fehlerhaft ist, kannst du 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:

Beachte, 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 du leicht sehen kannst, wer diese Zeile wann geändert hat. Danach folgen die Zeilennummer und der Inhalt der Datei. Beachte auch die ^1da177e4c3f4 Commit-Zeilen, wobei das ^-Präfix Zeilen angibt, daß diese Code-Zeilen mit dem allerersten Commit des Repositorys eingeführt wurden und seitdem unverändert geblieben sind. Das ist ein bisschen verwirrend, denn jetzt hast du mindestens drei verschiedene Möglichkeiten gesehen, wie Git das Zeichen ^ verwendet, um einen Commit SHA-1 zu modifizieren. Hier ist die Bedeutung eine andere.

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 du -C an git blame übergibst, analysiert Git die Datei, die du annotierst und versucht herauszufinden, woher die Codeschnipsel darin ursprünglich kamen, wenn sie von woanders kopiert wurden. Nehmen wir an, du zerlegst eine Datei namens GITServerHandler.m in mehrere Dateien, von denen eine GITPackUpload.m ist. Indem du GITPackUpload.m mit git blame -C aufrufst, annst du sehen, wo Teile des Codes ursprünglich herkamen:

Das ist wirklich nützlich. Normalerweise erhältst du als Original-Commit den Commit, mit dem du den Code kopiert hast, denn das ist das erste Mal, dass du diese Zeilen in dieser Datei angefasst hast. Mit der Option -C gibt dir Git den ursprünglichen Commit, in welchem du diese Zeilen geschrieben hast, auch wenn das in einer anderen Datei war.

Das Annotieren einer Datei hilft, wenn du weißt, wo das Problem liegt. Wenn du nicht weißt, was kaputt ist und es Dutzende oder Hunderte von Commits seit dem letzten funktionierendem Zustand gab, kannst du es mit git bisect versuchen. Der Befehl bisect führt eine binäre Suche durch deine Commit-Historie durch, um dir zu helfen so schnell wie möglich zu identifizieren, welcher Commit das Problem eingeführt hat.

Nehmen wir an, du hast gerade eine Version deines Codes in eine Produktionsumgebung released. Du erhältst einen Fehlerberichte über ein Verhalten, das so nicht in deiner Entwicklungsumgebung aufgetreten ist und du kannst dir nicht erklären, warum der Code sich so verhält. Du siehst dir deinem Code an und du kannst den Fehler reproduzieren. Du kannst jedoch nicht herausfinden, was schief läuft. Du kannst den Code teilen (engl. bisect), um es herauszufinden. Zuerst rufst du git bisect start auf. Dann benutzt du git bisect bad, um dem System mitzuteilen, dass der aktuelle Commit, auf dem du dich befindest nicht funktioniert. Dann musst du git bisect sagen, wann der letzte bekannte funktionierende Zustand war, indem du git bisect good <good_commit> verwendst:

Git hat herausgefunden, dass etwa 12 Commits zwischen dem Commit, den du als letzten guten Commit (v1.0) markiert hast, und der aktuellen schlechten Version liegen. Anschließend ist git zu dem mittleren Commit gewechselt (interner git checkout). Jetzt kannst du deinen 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. Du sagst Git das, indem du git bisect good tippst und so deine Reise fortsetzt:

Jetzt bist du auf einem anderen Commit. Du bist auf halbem Weg zwischen dem, den du gerade getestet hast und dem schlechten Commit. Du führst deinen Test noch einmal durch und stellst fest, dass dieser Commit fehlerhaft ist. Also sagst du 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 dir den SHA-1 des ersten fehlerhaften Commits und zeigt einige der Commit-Informationen und welche Dateien in diesem Commit verändert wurden, so dass du herausfinden kannst, was diesen Fehler eingeführt haben könnte:

Wenn du fertig bist, solltest du git bisect reset ausführen, um deinen HEAD wieder auf den Stand vor dem Start zurückzusetzen (ansonsten landest du in einem undefinierten Zustand):

Dies ist ein mächtiges Werkzeug, das dir helfen kann, hunderte von Commits in Minuten auf einen Fehler zu überprüfen. Wenn du ein Skript hast, das mit 0 als Rückgabewert, wenn das Projekt funktioniert und mit ungleich 0 als Rückgabewert, wenn das Projekt nicht funktioniert, kannst du git bisect vollständig automatisieren. Zuerst teilst du Git wieder den Umfang der Bisection mit, indem du die bekannten schlechten und guten Commits angibst. Du kannst dies tun, indem du dem Befehl bisect start den bekannten schlechten Commit als Ersten und den bekannten guten Commit als zweiten Parameter mitgibst:

Dabei wird automatisch test-error.sh bei jedem ausgecheckten Commit ausgeführt, bis Git den ersten fehlerhaften Commit findet. Du kannst auch etwas wie make or make tests oder was auch immer du hast, das automatische Tests für dich ausführt, nutzen.