git bisect

12. August 2019
git

Für die zügige Eingrenzung eines Fehlers gibt einem git das Kommando bisect an die Hand. Das macht nicht viel mehr als über einen binären Suchpfad einen Commit nach dem anderen auszuchecken, um diesen dann vom Benutzer bewerten zu lassen. Je nach Bewertung verzweigt sich der Pfad.

An einem Beispiel ist der Ablauf leichter nachvollziehbar.

Da bisect Commits auscheckt, dürfen im Arbeitsverzeichnis keine veränderten Dateien liegen. Der Ablauf selbst ist dann folgender. Zuerst aktiviert man bisect.

$ git bisect start

Anschließend gibt man einen Commit (0555589 = zugehöriger Hash) an, von dem man weiß, dass in diesem der Fehler noch nicht aufgetreten ist.

$ git bisect good 0555589

Ehe als letzter Konfigurationsschritt ein Commit angegeben wird, der den Fehler enthält. Wird kein Hash angegeben, so wird der Commit genommen auf den HEAD zeigt.

$ git bisect bad 

Git gibt dann die voraussichtliche Anzahl nötiger Schritte an, zum Auffinden des Commits mit dem der Fehler eingeführt wurde, und checkt den ersten Stand aus. Die ausgecheckte Version ist dann auf den Fehler abzuprüfen. Ein C-Programm muss z.B. kompiliert, gestartet und bedient, eine Web-Applikation im Browser geöffnet werden. Findet sich der Fehler, dann geht es mit

$ git bisect bad 

weiter, findet er sich nicht, dann gibt man

$ git bisect good

ein. Daraufhin wird der nächste Commit ausgecheckt und die Prüfung beginnt wieder von vorne. Das geht so lange bis der den Fehler einführende Commit ausfindig gemacht wurde.

$ git bisect good
6e5dad3b35a532bf1df05f31b79053a25dbfcb91 is the first bad commit
commit 6e5dad3b35a532bf1df05f31b79053a25dbfcb91
...

Dieser bleibt dann ausgecheckt und mit

$ git bisect reset

geht es zurück zum Ausgangspunkt. So kann der Befehl auch abgebrochen werden.

all-inkl & git & jekyll

5. Mai 2017