GIT czym jest każdy wie. Może poza tymi którym SVN założył bardzo ciemne okulary. Ale nie będę się dziś rozwodził nad przewagą jednych nad drugimi bo oba mają swoje wady i zalety.
Dziś natomiast postaram się przybliżyć problem debugowania aplikacji będących pod kontrolą repozytoriów GIT i tego jak bardzo łatwo można znaleźć błąd i miejsce w programie.
A pierwotni robili to tak…
Na początku przybliżę sytuację w której się znaleźliśmy nie raz. Jest sobie projekt nad którym pracuje wiele osób, jest masa kodu, a projekt ogólnie jest duuży. Pewnego pięknego dnia klient zgłasza nam problem z aplikacją. Co robimy? Albo odpalamy testy jednostkowe i mamy pozamiatane albo szukamy błędów nie wiedząc za bardzo gdzie on może siedzieć i czym był spowodowany. Cenna informacja to też od kiedy błąd siedzi u nas w kodzie.
No to szukamy, szukamy…. Mija godzina, i potem kolejna i w końcu udało się znaleźć błąd. Zadowoleni naprawiamy i gratulujemy sobie sukcesu. Ale czy tędy droga?
Bisect czyli…
… narzędzie pochodzące z pakietu GIT które pozwala na przeszukiwanie repozytorium metodą binarną. To tak z grubsza.
Sednem tej metody jest określenie punktów marginalnych. Wydając polecenie:
git bisect start bad good
rozpoczynamy pracę. Start to po prostu start. Natomiast bad i good są to numery rewizji, tagi lub inne dziwactwa które git łyka. Są to tzw. skrajne stany które chcemy sprawdzić.
Czyli Wiemy że w rewizji 1.5 wszystko działało w naszej aplikacji a natomiast w obecnym stanie czyli HEAD nie działa. Wykonujemy więc polecenie:
git bisect start 1.5 HEAD
Co się stało. Git cofną nas do ostatniej dobrej rewizji (zrobił tak naprawdę checkout nr_rewizji). Sprawdzamy sobie teraz nasz kod czy działa. Działa? Ok. To nie to miejsce, więc oznaczamy tą rewizję jako dobrą. A robimy to tak:
git bisect good
Analogicznie złą jako bad. Ale o tym za chwilę.
Lecimy dalej bo tu się zaczyna cała magia narzędzia. Po wydaniu komendy ww. GIT nie przeskakuje do następnej rewizji ale mniej więcej na połowę zakresu między wybranymi rewizjami na początku. Po każdym wydanym poleceniu good i bad analogicznie przeskakuję coraz ciaśniej w głąb pomniejszanego zakresu. Skutkuje to znacznie ilość rewizji które musimy przetestować do kilku.
Po prześledzeniu czy serwis działa czy też nie i wydając odpowiednie komendy potwierdzające czy działa czy nie dochodzimy do momentu gdy GIT wypluje nam w wyniku nr. 1-sze rewizji w której pojawił się nasz szukany błąd. Dzięki temu możemy przeszukać tylko ten konkretny commit i naprawić nasz błąd. Aby zakończyć pracę z bisect wydajemy polecenie:
git bisect reset
Zresetuje to nam stan i powróci do miejsca w którym pracowaliśmy przed rozpoczęciem pracy.
Małe podsumowanie
Tym oto małym wpisem chciałem tylko nakreślić możliwość i istnienie bisect jako narzędzia do bardzo szybkiego debugowanie dużej ilości rewizji podczas braku wiedzy o czasie kiedy zaszło niepożądane zachowanie.
Polecam naprawdę zabawę z tym ponieważ bardzo ułatwia pracę. Mnie osobiście już się przydało wiele razy w momencie zagalopowania się z ilością commitów a nie wiedziałem gdzie i kiedy pojawił się błąd. Przydatne w sytuacjach gdy często modyfikujemy ten sam kod a nie wiemy w którym momencie zrobiliśmy skrzata.
Tym miłym akcentem żegnam się i odsyłam do lektury książki Pro Git w której jest to ładnie opisane.