Ostatnio natknąłem się na sytuację, która miejsca mieć nie powinna... a mimo to zdarza się w każdym chyba projekcie dość regularnie. Otóż podczas klikania po aplikacji w przypadkowym teście okazało się, że jedna z podstawowych funkcjonalności nie działa. Nie wykonywał się POST jakiejś prostej formy. Dziw nad dziwy... kod wyglądał OK, przejrzenie ostatnich commitów nie wykazało żadnych kluczowych zmian, a mimo to - nie działa.
Nieocenionym wręcz narzędziem do znajdowania przyczyn takich wypadków jest komenda git bisect. Pozwala ona na znalezienie jednego konkretnego commita, który jest be i psuje nam aplikację. Po kolei:
1) Najpierw cofnąłem się o 2 tygodnie do wersji aktualnie rezydującej na testowym serwerze online - byłem pewny że tam działa. Na szczęście te dwa tygodnie nie były zbytnio pracowite, więc miałem tylko 57 commitów dzielących mnie od działającej wersji do przetestowania.
2) Zweryfikowałem że u mnie lokalnie również działa
3) Znajdując się w tym commicie wykonałem komendę mówiącą gitowi o co mi chodzi:
1: git bisect start
2: git bisect good
3: git bisect bad master
Oznacza to: "zacznij proces bisecting zważywszy na to, że aktualny commit jest OK, a HEAD MASTER nie działa". Git przyjął instrukcje i odpowiedział:
1: Bisecting: 57 revisions left to test after this (roughly 6 steps)
2: [98d7fc1288f269f107bc74f7451de61b5cfad2db] menu i inne
Czyli z testowania 57 commitów mam do przetestowania maksymalnie 6.
4) W tym momencie git dzieli te 57 commitów na dwie części i robi checkout na środkowym (23 czy 24 z nich) z nich. Kompiluję, sprawdzam czy działa... Działa. A więc:
5) Teraz git dzieli na pół commity od tego dobrego do mastera, robi checkout na środkowym... i tak w koło (nomen-omen) Macieju do momentu, gdy znowu coś przestaje działać. Wtedy:
i git wybiera odpowiednią połówkę żeby znowu zawęzić potencjalnych kandydatów psujących funkcjonalność.
6) W końcu dochodzimy do sedna i git identyfikuje "the chosen one":
1: $ git bisect bad
2: a8cf2f65edc01a34dc21f5f33ebc44e234fd4e9e is the first bad commit
3: commit a8cf2f65edc01a34dc21f5f33ebc44e234fd4e9e
4: Author: Maciej Aniserowicz <...>
5: Date: Sun Apr 17 18:36:21 2011 +0200
6:
7: custom branches required
8:
9: id #265
10:
11: :040000 040000 6b21e3f88a0b39ea3076cb095abc9a5b68c35157 fef4e470856873691b55587d55f5c820ddec790e M src
Co teraz? Teraz z wdzięcznością wystarczy zakończyć proces bisecting:
, sprawdzić co w danym commicie mogło spowodować złe zachowanie aplikacji, poprawić i cieszyć się dalej życiem.
Jest to kolejny dowód na wspaniałość gita oraz powód do dbania o porządek w commitach. W moim przypadku ten commit modyfikował tylko cztery pliki, więc znalezienie i naprawienie błędu było zadaniem po prostu banalnym. Polecam!
PS Na czas takich testów z powodów wydajnościowych zalecam wyłączenie Resharpera