Git
Halbieren / Finden fehlerhafter Commits

Syntax

• git bisect <subcommand> <options>

• git bisect start <bad> [<good>...]

• git bisect reset

• git bisect good

• git bisect bad

Binäre Suche (git bisect)

git bisect können Sie anhand einer binären Suche herausfinden, welches Commit einen Fehler eingeführt hat.

Beginnen Sie mit der Halbierung einer Sitzung, indem Sie zwei Commit-Referenzen angeben: ein gutes Commit vor dem Fehler und ein schlechtes Commit nach dem Fehler. Im Allgemeinen ist das schlechte Commit HEAD .

# start the git bisect session
$ git bisect start

# give a commit where the bug doesn't exist
$ git bisect good 49c747d

# give a commit where the bug exist
$ git bisect bad HEAD

git startet eine binäre Suche: Die Revision wird in zwei Hälften geteilt und das Repository auf die Zwischenversion umgestellt. Überprüfen Sie den Code, um festzustellen, ob die Revision gut oder schlecht ist:

# tell git the revision is good,
# which means it doesn't contain the bug
$ git bisect good

# if the revision contains the bug,
# then tell git it's bad
$ git bisect bad

git wird die binäre Suche nach jeder noch verbleibenden Teilmenge der fehlerhaften Revisionen fortsetzen, je nach Ihren Anweisungen. git wird eine einzelne Revision präsentieren, die, sofern Ihre Flags nicht korrekt waren, genau die Revision darstellt, in der der Fehler eingeführt wurde.

git bisect reset anschließend daran, git bisect reset auszuführen, git bisect reset die halbierte Sitzung zu beenden und zu HEAD zurückzukehren.

$ git bisect reset

Wenn Sie ein Skript haben, das nach dem Fehler suchen kann, können Sie den Prozess mit folgendem automatisieren:

$ git bisect run [script] [arguments]

Dabei ist [script] der Pfad zu Ihrem Skript und [arguments] Argumente, die an Ihr Skript übergeben werden sollen.

Wenn Sie diesen Befehl ausführen, wird automatisch die binäre Suche ausgeführt. In jedem Schritt werden git bisect good oder git bisect bad abhängig vom Exit-Code Ihres Skripts. Das Beenden mit 0 zeigt good , das Beenden mit 1-124, 126 oder 127 zeigt schlecht an. 125 gibt an, dass das Skript diese Version nicht testen kann (was einen git bisect skip auslöst).

Halbautomatisch finden Sie ein fehlerhaftes Commit

Stellen Sie sich vor, Sie befinden sich im master Zweig und etwas funktioniert nicht wie erwartet (eine Regression wurde eingeführt), aber Sie wissen nicht, wo. Alles, was Sie wissen, ist, dass in der letzten Version gearbeitet wurde (was z. B. mit einem Tag versehen wurde oder Sie kennen den Commit-Hash, nehmen wir hier old-rel ).

Git hat Hilfe für Sie, um das fehlerhafte Commit zu finden, das die Regression mit einer sehr geringen Anzahl von Schritten einleitete (binäre Suche).

Beginnen Sie zunächst mit der Halbierung:

git bisect start master old-rel

Dies sagt git, dass master eine defekte Version ist (oder die erste defekte Version) und old-rel die letzte bekannte Version ist.

Git wird nun einen losgelösten Kopf in der Mitte beider Commits auschecken. Jetzt können Sie Ihre Tests durchführen. Abhängig davon, ob es funktioniert oder nicht

git bisect good

oder

git bisect bad

. Falls dieses Commit nicht getestet werden kann, können Sie es einfach git reset und testen. Git kümmert sich darum.

Nach wenigen Schritten gibt git den fehlerhaften Commit-Hash aus.

Um den zweigeteilten Vorgang abzubrechen, wird nur noch ausgegeben

git bisect reset

und git stellt den vorherigen Zustand wieder her.