Git Bisect-Tutorial

Das Kommentieren Ihrer Commits ist ein wesentlicher Bestandteil der Pflege von nachvollziehbarem Code. Es hilft Ihnen, Probleme zu verfolgen. Es ist jedoch eine mühsame Aufgabe, einen Fehler allein anhand von Kommentaren zu finden. Es kann lange dauern, die gesamte Historie zu durchsuchen und herauszufinden, welcher Commit der Übeltäter ist.

Der Befehl git bisect bietet eine Möglichkeit, den Fehlererkennungsprozess zu beschleunigen. So können Sie das Problem schneller lokalisieren. Mit git bisect können Sie eine Reihe von Commits definieren, von denen Sie vermuten, dass sie den problematischen Code enthalten, und dann binäre Eliminationsmethoden verwenden, um den Anfang des Problems zu finden. Das Finden von Fehlern wird schneller und einfacher.

Lassen Sie uns ein Beispiel einrichten und einige Testfälle ausführen, um zu sehen, wie es funktioniert.

Beispiel-Setup

In unserem Beispiel erstellen wir einen Test.txt-Datei und fügen Sie bei jedem Commit eine neue Zeile in die Datei ein. Nach 16 Commits sieht der Endzustand der Datei so aus:

Hier ist mein guter Code 1
Hier ist mein guter Code 2
Hier ist mein guter Code 3
Hier ist mein guter Code 4
Hier ist mein guter Code 5
Hier ist mein guter Code 6
Hier ist mein guter Code 7
Hier ist mein guter Code 8
Hier ist mein schlechter Code 1 <-- BUG INTRODUCED HERE
Hier ist mein schlechter Code 2
Hier ist mein schlechter Code 3
Hier ist mein schlechter Code 4
Hier ist mein schlechter Code 5
Hier ist mein schlechter Code 6
Hier ist mein schlechter Code 7
Hier ist mein schlechter Code 8
Hier ist mein schlechter Code 9

Im obigen Beispiel ist der Fehler nach 8 Commits in den Code eingedrungen. Wir haben den Code auch nach der Einführung des Fehlers weiter entwickelt.

Sie können einen Ordner namens my_bisect_test erstellen und die folgenden Befehle aus dem Ordner verwenden, um die Beispielsituation zu erstellen:

git init
echo "Hier ist mein guter Code 1" > test.TXT
git add -A && git commit -m "Mein Commit 1"
echo "Hier ist mein guter Code 2" >> Test.TXT
git add -A && git commit -m "Mein Commit 2 (v1.0.0)"
echo "Hier ist mein guter Code 3" >> Test.TXT
git add -A && git commit -m "Mein Commit 3"
echo "Hier ist mein guter Code 4" >> Test.TXT
git add -A && git commit -m "Mein Commit 4"
echo "Hier ist mein guter Code 5" >> Test.TXT
git add -A && git commit -m "Mein Commit 5 (v1.0.1)"
echo "Hier ist mein guter Code 6" >> Test.TXT
git add -A && git commit -m "Mein Commit 6"
echo "Hier ist mein guter Code 7" >> Test.TXT
git add -A && git commit -m "Mein Commit 7 (v1.0.2)"
echo "Hier ist mein guter Code 8" >> Test.TXT
git add -A && git commit -m "Mein Commit 8"
echo "Hier ist mein schlechter Code 1" > test.TXT
git add -A && git commit -m "Mein Commit 9"
echo "Hier ist mein schlechter Code 2" >> Test.TXT
git add -A && git commit -m "Mein Commit 10"
echo "Hier ist mein schlechter Code 3" >> Test.TXT
git add -A && git commit -m "Mein Commit 11"
echo "Hier ist mein schlechter Code 4" >> Test.TXT
git add -A && git commit -m "Mein Commit 12 (v1.0.3)"
echo "Hier ist mein schlechter Code 5" >> Test.TXT
git add -A && git commit -m "Mein Commit 13"
echo "Hier ist mein schlechter Code 6" >> Test.TXT
git add -A && git commit -m "Mein Commit 14"
echo "Hier ist mein schlechter Code 7" >> Test.TXT
git add -A && git commit -m "Mein Commit 15 (v1.0.4)"
echo "Hier ist mein schlechter Code 8" >> Test.TXT
git add -A && git commit -m "Mein Commit 16"

Verlauf prüfen

Wenn Sie sich den Verlauf der Commits ansehen, sehen Sie Folgendes:

$ git log
begehen 3023b63eb42c7fadc93c2dd18b532a44a0a6888a
Autor: Zak H
Datum: So. 31. Dez. 23:07:27 2017 -0800
Mein Commit 17
Commit 10ef0286d6459cd5dea5038a54edf36fc9bfe4c3
Autor: Zak H
Datum: So. 31. Dez. 23:07:25 2017 -0800
Mein Commit 16
begehen 598d4c4acaeb14cda0552b6a92aa975c436d337a
Autor: Zak H
Datum: So. 31. Dez. 23:07:23 2017 -0800
Mein Commit 15 (v1.0.4)
begehen b9678b75ac93d532eed22ec2c6617e5a9d70fe7b
Autor: Zak H
Datum: So. 31. Dez. 23:07:21 2017 -0800
Mein Commit 14
begehen eb3f2f7b0ebedb732ecb5f18bee786cd3cbbb521
Autor: Zak H
Datum: So. 31. Dez. 23:07:19 2017 -0800
Mein Commit 13
begehen 3cb475a4693b704793946a878007b40a1ff67cd1
Autor: Zak H
Datum: So. 31. Dez. 23:07:17 2017 -0800
Mein Commit 12 (v1.0.3)
Commit 0419a38d898e28c4db69064478ecab7736700310
Autor: Zak H
Datum: So. 31. Dez. 23:07:15 2017 -0800
Mein Commit 11
begehen 15bc59201ac1f16aeaa233eb485e81fad48fe35f
Autor: Zak H
Datum: So. 31. Dez. 23:07:13 2017 -0800
Mein Commit 10
begehen a33e366ad9f6004a61a468b48b36e0c0c802a815
Autor: Zak H
Datum: So. 31. Dezember 23:07:11 2017 -0800
Mein Commit 9
Commit ead472d61f516067983d7e29d548fc856d6e6868
Autor: Zak H
Datum: So. 31. Dez. 23:07:09 2017 -0800
Mein Commit 8
begehen 8995d427668768af88266f1e78213506586b0157
Autor: Zak H
Datum: So. 31. Dez. 23:07:07 2017 -0800
Mein Commit 7 (v1.0.2)
Commit be3b341559752e733c6392a16d6e87b5af52e701
Autor: Zak H
Datum: So. 31. Dez. 23:07:05 2017 -0800
Mein Commit 6
Commit c54b58ba8f73fb464222f30c90aa72f60b99bda9
Autor: Zak H
Datum: So. 31. Dez. 23:07:03 2017 -0800
Mein Commit 5 (v1.0.1)
begehen 264267111643ef5014e92e23fd2f306a10e93a64
Autor: Zak H
Datum: So. 31. Dez. 23:07:01 2017 -0800
Mein Commit 4
Commit cfd7127cd35f3c1a55eb7c6608ecab75be30b208
Autor: Zak H
Datum: So. 31. Dezember 23:06:59 2017 -0800
Mein Commit 3
begehen 3f90793b631ddce7be509c36b0244606a2c0e8ad
Autor: Zak H
Datum: So. 31. Dezember 23:06:57 2017 -0800
Mein Commit 2 (v1.0.0)
begehen cc163adb8a3f7b7b52411db2b3d8bab9b7fb191e
Autor: Zak H
Datum: So. 31. Dez. 23:06:55 2017 -0800
Mein Commit 1

Selbst mit nur einer Handvoll Commits können Sie sehen, dass es schwierig ist, den Commit zu lokalisieren, der den Fehler ausgelöst hat.

Den Fehler finden

Lassen Sie uns git log -online verwenden, um eine bereinigte Version des Commit-Verlaufs anzuzeigen.

$ git log --oneline
3023b63 Mein Commit 17
10ef028 Mein Commit 16
598d4c4 Mein Commit 15 (v1.0.4)
b9678b7 Mein Commit 14
eb3f2f7 Mein Commit 13
3cb475a Mein Commit 12 (v1.0.3)
0419a38 Mein Commit 11
15bc592 Mein Commit 10
a33e366 Mein Commit 9
ead472d Mein Commit 8
8995d42 Mein Commit 7 (v1.0.2)
be3b341 Mein Commit 6
c54b58b Mein Commit 5 (v1.0.1)
2642671 Mein Commit 4
cfd7127 Mein Commit 3
3f90793 Mein Commit 2 (v1.0.0)
cc163ad Mein Commit 1

Wir wollen die Situation finden, in der die Zeile „Hier ist mein schlechter Code 1“ <- BUG INTRODUCED HERE” entered the picture.

Situation 1

Angenommen, wir erinnern uns, dass unser Code bis v1 gut war.0.2 und wir wollen von diesem Moment bis zum letzten Commit überprüfen. Wir starten zuerst den Bisect-Befehl:

$ git halbiert start

Wir stellen die gute Grenze und die schlechte Grenze bereit (kein Hash bedeutet den neuesten Code):

$ git halbiert gut 8995d42
$ git halbieren schlecht

Ausgabe:

Halbieren: 4 Revisionen zum Testen danach (ungefähr 2 Schritte)
[3cb475a4693b704793946a878007b40a1ff67cd1] Mein Commit 12 (v1.0.3)

Der Bisect-Befehl hat den Mittelpunkt in unserem definierten Bereich gefunden und den Code automatisch auf Commit 12 . verschoben. Wir können unseren Code jetzt testen. In unserem Fall werden wir den Inhalt von test ausgeben.TXT:

$ Katzentest.TXT

Ausgabe:

Wir sehen, dass der Testzustand.txt befindet sich im Post-Bug-Zustand. Es ist also in einem schlechten Zustand. Also lassen wir den Befehl bisect wissen:

$ git halbieren schlecht

Ausgabe:

Halbieren: Danach noch 2 Revisionen zum Testen (ungefähr 1 Schritt)
[a33e366ad9f6004a61a468b48b36e0c0c802a815] Mein Commit 9

Es verschiebt unseren Code zum Commit 9 commit. Wir testen noch einmal:

$ Katzentest.TXT

Ausgabe:

Wir sehen, dass wir den Ausgangspunkt des Fehlers gefunden haben. Der Commit „a33e366 Mein Commit 9“ ist der Schuldige.

Schließlich haben wir alles wieder normalisiert, indem wir:

$ git bisect reset

Ausgabe:

Vorherige HEAD-Position war a33e366… Mein Commit 9
Auf Zweig 'master' gewechselt

Situation 2

Versuchen wir im selben Beispiel eine Situation, in der ein anderer Entwickler mit der Prämisse beginnt, dass der Fehler zwischen v1 . eingeführt wurde.0.0 und v1.0.3. Wir können den Prozess erneut starten:

$ git halbiert start
$ git halbieren gut 3f90793
$ git halbiert schlecht 3cb475a

Ausgabe:

Halbieren: 4 Revisionen zum Testen danach (ungefähr 2 Schritte)
[8995d427668768af88266f1e78213506586b0157] Mein Commit 7 (v1.0.2)

Bisect hat unseren Code auf Commit 7 oder v1 verschoben.0.2. Lassen Sie uns unseren Test durchführen:

$ Katzentest.TXT

Ausgabe:

Hier ist mein guter Code 1
Hier ist mein guter Code 2
Hier ist mein guter Code 3
Hier ist mein guter Code 4
Hier ist mein guter Code 5
Hier ist mein guter Code 6
Hier ist mein guter Code 7

Wir sehen keinen schlechten Code. Also, lass git bisect wissen:

$ git halbieren gut

Ausgabe:

Halbieren: Danach noch 2 Revisionen zum Testen (ungefähr 1 Schritt)
[a33e366ad9f6004a61a468b48b36e0c0c802a815] Mein Commit 9

Es hat uns bewegt, 9 . zu begehen. Wir testen noch einmal:

$ Katzentest.TXT

Ausgabe:

Wir haben wieder den Commit gefunden, der den Fehler eingeführt hat. Es war der Commit „a33e366 Mein Commit 9“. Obwohl wir mit dem unterschiedlichen Verdachtsbereich begonnen haben, haben wir in wenigen Schritten den gleichen Fehler gefunden.

Lassen Sie uns zurücksetzen:

$ git bisect reset

Ausgabe:

Vorherige HEAD-Position war a33e366… Mein Commit 9
Auf Zweig 'master' gewechselt

Fazit

Wie Sie am Beispiel sehen können, können wir mit git bisect ein Problem schneller lokalisieren. Es ist ein großartiges Werkzeug, um Ihre Produktivität zu steigern. Anstatt den gesamten Verlauf der Commits durchzugehen, können Sie das Debugging systematischer angehen.

Weitere Studie:

https://git-scm.com/docs/git-bisect
https://git-scm.com/book/de/v2/Git-Tools-Debugging-mit-Git