Git Bisect Tutorial
Polecenie Git Bisect zapewnia sposób na przyspieszenie procesu wykrywania błędów. Pozwala szybciej wskazać problem. Dzięki GIT Bisect możesz zdefiniować szereg zobowiązań, które podejrzewasz, że masz problematyczny kod, a następnie użyć metod eliminacji binarnej, aby znaleźć początek problemu. Znalezienie błędów staje się szybsze i łatwiejsze.
Skonfigurujmy przykład i uruchom kilka przypadków testowych, aby zobaczyć, jak to działa.
Przykładowa konfiguracja
W naszym przykładzie utworzymy test.plik txt i dodaj nową linię do pliku z każdym zatwierdzeniem. Po 16 zobowiązaniach ostateczny stan pliku będzie wyglądał tak:
Oto mój dobry kod 1
Oto mój dobry kod 2
Oto mój dobry kod 3
Oto mój dobry kod 4
Oto mój dobry kod 5
Oto mój dobry kod 6
Oto mój dobry kod 7
Oto mój dobry kod 8
Oto mój zły kod 1 <-- BUG INTRODUCED HERE
Oto mój zły kod 2
Oto mój zły kod 3
Oto mój zły kod 4
Oto mój zły kod 5
Oto mój zły kod 6
Oto mój zły kod 7
Oto mój zły kod 8
Oto mój zły kod 9
W powyższym przykładzie błąd dostał się do kodu po 8 zobowiązania. Opracowywaliśmy kod nawet po wprowadzeniu błędu.
Możesz utworzyć folder o nazwie my_bisect_test i użyć następujących poleceń z wnętrza folderu, aby utworzyć przykładową sytuację:
Git Init
Echo „Tutaj jest mój dobry kod 1”> test.tekst
Git dodaj -a && git commit -m „My Commit 1”
Echo „Oto mój dobry kod 2” >> test.tekst
git dodaj -a && git commit -m "mój commit 2 (v1.0.0) ”
Echo „Oto mój dobry kod 3” >> test.tekst
Git dodaj -a && git commit -m „My Commit 3”
Echo „Tutaj jest mój dobry kod 4” >> test testowy.tekst
git dodaj -a && git commit -m „My Commit 4”
Echo „Oto mój dobry kod 5” >> test.tekst
git dodaj -a && git commit -m "mój commit 5 (v1.0.1) ”
Echo „Oto mój dobry kod 6” >> test testowy.tekst
git dodaj -a && git commit -m „My Commit 6”
Echo „Oto mój dobry kod 7” >> test.tekst
git dodaj -a && git commit -m "mój zatwierdzenie 7 (v1.0.2) ”
Echo „Oto mój dobry kod 8” >> test.tekst
Git dodaj -a && git commit -m „My Commit 8”
Echo „Tutaj jest mój zły kod 1”> test.tekst
git dodaj -a && git commit -m „My Commit 9”
Echo „Oto mój zły kod 2” >> test testowy.tekst
Git dodaj -a && git commit -m „My Commit 10”
Echo „Oto mój zły kod 3” >> test.tekst
Git dodaj -a && git commit -m „My Commit 11”
Echo „Oto mój zły kod 4” >> test.tekst
git dodaj -a && git commit -m "mój commit 12 (v1.0.3) ”
Echo „Oto mój zły kod 5” >> test.tekst
Git dodaj -a && git commit -m „My Commit 13”
Echo „Oto mój zły kod 6” >> test testowy.tekst
Git dodaj -a && git commit -m „My Commit 14”
Echo „Oto mój zły kod 7” >> test.tekst
git dodaj -a && git commit -m "mój commit 15 (v1.0.4) ”
Echo „Oto mój zły kod 8” >> test testowy.tekst
Git dodaj -a && git commit -m „My Commit 16”
Sprawdzanie historii
Jeśli spojrzysz na historię zobowiązań, zobaczysz następujące:
$ git log
zatwierdzenie 3023B63EB42C7FADC93C2DD18B532A44A0A6888A
Autor: Zak H
Data: Sun 31 grudnia 23:07:27 2017 -0800
Moje zatwierdzenie 17
zatwierdzić 10EF0286D6459CD5DEA5038A54EDF36FC9BFE4C3
Autor: Zak H
Data: Sun 31 grudnia 23:07:25 2017 -0800
Moje zatwierdzenie 16
zatwierdzenie 598d4c4acaeB14CDA0552B6A92AA975C436D337A
Autor: Zak H
Data: Sun 31 grudnia 23:07:23 2017 -0800
Moje zatwierdzenie 15 (v1.0.4)
Commit B9678B75AC93D532EED22EC2C6617E5A9D70FE7B
Autor: Zak H
Data: Sun 31 grudnia 23:07:21 2017 -0800
Moje zatwierdzenie 14
zatwierdzić EB3F2F7B0EBEDB732ECB5F18BEE786CD3CBBB521
Autor: Zak H
Data: Sun 31 grudnia 23:07:19 2017 -0800
Moje zatwierdzenie 13
zatwierdzenie 3CB475A4693B704793946A878007B40A1FF67CD1
Autor: Zak H
Data: Sun 31 grudnia 23:07:17 2017 -0800
Moje zatwierdzenie 12 (v1.0.3)
zatwierdzić 0419A38D898E28C4DB69064478ECAB7736700310
Autor: Zak H
Data: Sun 31 grudnia 23:07:15 2017 -0800
Moje zatwierdzenie 11
zatwierdzić 15BC59201AC1F16AEAA233EB485E81FAD48FE35F
Autor: Zak H
Data: Sun 31 grudnia 23:07:13 2017 -0800
Moje zatwierdzenie 10
zatwierdzenie A33E366AD9F6004A61A468B48B36E0C0C802A815
Autor: Zak H
Data: Sun 31 grudnia 23:07:11 2017 -0800
Moje zatwierdzenie 9
zatwierdzić EAD472D61F516067983D7E29D548FC856D6E6868
Autor: Zak H
Data: Sun 31 grudnia 23:07:09 2017 -0800
Moje zatwierdzenie 8
zatwierdzić 8995D427668768AF88266F1E78213506586B0157
Autor: Zak H
Data: Sun 31 grudnia 23:07:07 2017 -0800
Moje zatwierdzenie 7 (v1.0.2)
zatwierdzenie BE3B341559752E733C6392A16D6E87B5AF52E701
Autor: Zak H
Data: Sun 31 grudnia 23:07:05 2017 -0800
Moje zatwierdzenie 6
zatwierdzenie C54B58BA8F73FB464222F30C90AA72F60B99BDA9
Autor: Zak H
Data: Sun 31 grudnia 23:07:03 2017 -0800
Moje zatwierdzenie 5 (v1.0.1)
zatwierdzenie 264267111643EF5014E92E23FD2F306A10E93A64
Autor: Zak H
Data: Sun 31 grudnia 23:07:01 2017 -0800
Moje zatwierdzenie 4
zatwierdzić CFD7127CD35F3C1A55EB7C6608ECAB75BE30B208
Autor: Zak H
Data: Sun 31 grudnia 23:06:59 2017 -0800
Moje zatwierdzenie 3
zatwierdzić 3F90793B631DDCE7BE509C36B0244606A2C0E8AD
Autor: Zak H
Data: Sun 31 grudnia 23:06:57 2017 -0800
Moje zatwierdzenie 2 (v1.0.0)
Commit CC163ADB8A3F7B7B52411DB2B3D8BAB9B7FB191E
Autor: Zak H
Data: Sun 31 grudnia 23:06:55 2017 -0800
Moje zatwierdzenie 1
Nawet mając tylko garść zobowiązań, widać, że trudno jest wskazać zatwierdzenie, które rozpoczęło błąd.
Znalezienie błędu
Użyjmy log -log -nline, aby zobaczyć bardziej oczyszczoną wersję historii zatwierdzenia.
$ git log -linia
3023b63 moje zatwierdzenie 17
10EF028 Moje zatwierdzenie 16
598d4c4 moje zatwierdzenie 15 (v1.0.4)
B9678B7 Moje zatwierdzenie 14
eb3f2f7 moje zatwierdzenie 13
3CB475a moje zatwierdzenie 12 (v1.0.3)
0419a38 Moje zatwierdzenie 11
15BC592 moje zatwierdzenie 10
A33E366 Moje zatwierdzenie 9
ead472d moje zatwierdzenie 8
8995d42 moje zatwierdzenie 7 (v1.0.2)
be3b341 moje zatwierdzenie 6
C54B58B My Commit 5 (v1.0.1)
2642671 Moje zatwierdzenie 4
CFD7127 moje zatwierdzenie 3
3F90793 moje zatwierdzenie 2 (v1.0.0)
CC163AD My Commit 1
Chcemy znaleźć sytuację, w której wiersz „Oto mój zły kod 1 <- BUG INTRODUCED HERE” entered the picture.
Sytuacja 1
Załóżmy, że pamiętamy, że nasz kod był dobry do wersji 1.0.2 i chcemy sprawdzić od tego momentu, aż do najnowszego zatwierdzenia. Najpierw rozpoczynamy polecenie Bisect:
$ git bisect start
Zapewniamy dobrą granicę i złą granicę (brak skrótu oznacza najnowszy kod):
$ git bisect Good 8995d42
$ git bisect źle
Wyjście:
Bisektowanie: 4 zmiany pozostawione do przetestowania po tym (około 2 kroki)
[3CB475A4693B704793946A878007B40A1FF67CD1] My Commit 12 (v1.0.3)
Polecenie Bisect znalazło punkt środkowy w naszym określonym zakresie i automatycznie przesunął kod, aby zatwierdzić 12. Możemy teraz przetestować nasz kod. W naszym przypadku zamierzamy wyprowadzić zawartość testu.tekst:
Test $ CAT.tekst
Wyjście:
Oto mój dobry kod 1
Oto mój dobry kod 2
Oto mój dobry kod 3
Oto mój dobry kod 4
Oto mój dobry kod 5
Oto mój dobry kod 6
Oto mój dobry kod 7
Oto mój dobry kod 8
Oto mój zły kod 1 <-- BUG INTRODUCED HERE
Oto mój zły kod 2
Oto mój zły kod 3
Oto mój zły kod 4
Widzimy, że stan testu.TXT jest w stanie post-bug. Więc jest w złym stanie. Dlatego pozwalamy Bisect Command:
$ git bisect źle
Wyjście:
Bisektowanie: 2 poprawki pozostawione do przetestowania po tym (około 1 krok)
[A33E366AD9F6004A61A468B48B36E0C0C802A815] MOJE COMPIM 9
Przenosi nasz kod, aby zatwierdzić 9. Ponownie testujemy:
Test $ CAT.tekst
Wyjście:
Oto mój dobry kod 1
Oto mój dobry kod 2
Oto mój dobry kod 3
Oto mój dobry kod 4
Oto mój dobry kod 5
Oto mój dobry kod 6
Oto mój dobry kod 7
Oto mój dobry kod 8
Oto mój zły kod 1 <-- BUG INTRODUCED HERE
Widzimy, że znaleźliśmy punkt początkowy błędu. Commit „A33E366 My Commit 9” jest winowajcą.
Wreszcie, odłożyliśmy wszystko do normy:
$ git bisect reset
Wyjście:
Poprzednia pozycja główna była A33E366… moje zatwierdzenie 9
Przełączony na „mistrz” oddziału
Sytuacja 2
W tym samym przykładzie wypróbujmy sytuację, w której inny programista zaczyna od założenia, że błąd został wprowadzony między V1.0.0 i v1.0.3. Możemy rozpocząć proces ponownie:
$ git bisect start
$ git bisect Good 3F90793
$ git bisect Bad 3CB475a
Wyjście:
Bisektowanie: 4 zmiany pozostawione do przetestowania po tym (około 2 kroki)
[8995D427668768AF88266F1E78213506586B0157] moje zatwierdzenie 7 (v1.0.2)
Bisect przeniósł nasz kod, aby zatwierdzić 7 lub v1.0.2. Uruchommy nasz test:
Test $ CAT.tekst
Wyjście:
Oto mój dobry kod 1
Oto mój dobry kod 2
Oto mój dobry kod 3
Oto mój dobry kod 4
Oto mój dobry kod 5
Oto mój dobry kod 6
Oto mój dobry kod 7
Nie widzimy żadnego złego kodu. Więc daj Gitowi Bisect:
$ git bisect good
Wyjście:
Bisektowanie: 2 poprawki pozostawione do przetestowania po tym (około 1 krok)
[A33E366AD9F6004A61A468B48B36E0C0C802A815] MOJE COMPIM 9
Przeniosło nas do zatwierdzenia 9. Ponownie testujemy:
Test $ CAT.tekst
Wyjście:
Oto mój dobry kod 1
Oto mój dobry kod 2
Oto mój dobry kod 3
Oto mój dobry kod 4
Oto mój dobry kod 5
Oto mój dobry kod 6
Oto mój dobry kod 7
Oto mój dobry kod 8
Oto mój zły kod 1 <-- BUG INTRODUCED HERE
Ponownie znaleźliśmy zatwierdzenie, które wprowadziło błąd. To było zatwierdzenie „A33E366 My Commit 9”. Mimo że zaczęliśmy od różnego zakresu podejrzeń, znaleźliśmy ten sam błąd w kilku krokach.
Zresetujmy:
$ git bisect reset
Wyjście:
Poprzednia pozycja główna była A33E366… moje zatwierdzenie 9
Przełączony na „mistrz” oddziału
Wniosek
Jak widać z przykładu, Git Bisect pozwala nam szybciej wskazać problem. Jest to świetne narzędzie do zwiększenia wydajności. Zamiast przeglądać całą historię zatwierdzeń, możesz zastosować bardziej systematyczne podejście do debugowania.
Dalsze badanie:
https: // git-scm.COM/DOCS/GIT-BISECT
https: // git-scm.com/book/en/v2/git-tools-debugging-with-git