Repozytorium kodu to jedno z podstawowych narzędzi programisty, bez którego żaden profesjonalista nie może się obejść. W nim jeden z najważniejszych produktów jaki tworzymy obok głównego aplikacji.
Historia produktu zapisana w repozytorium kodu
Tworząc aplikację z każdym commitem tworzy się historia. Tworzy się ciąg kroków, jakie doprowadziły aplikację do stanu dzisiejszego. To co możemy w tej historii wyczytać jest czasem bardzo cenne. Kiedy? Po pierwsze wtedy, gdy chcemy przypomnieć sobie co zrobiliśmy od wydania ostatniej wersji. Po drugie gdy chcemy poprawić jakiś błąd.
Release Notes z historii commitów
Pracując w zespole większym niż jednoosobowym i wydając kolejne wersje (bez względu czy to jest aplikacja pudełkowa, webowa czy usługa) często potrzebujemy śledzić co w kolejnych wersjach zostało wydane. Historia kolejnych commitów staje się w takiej sytuacji bardzo pomocna – oczywiście przy założeniu, że dajemy przyzwoite nazwy do commitów – i zakładam, że na dzień dzisiejszy mało osób jest tak nierozsądnych aby robić commity bez odpowiednich komunikatów. Można pójść nawet dalej. Jeśli mamy jakiś sensowny automatyczny build to możemy z automatu tagować kolejne wydania wersji i wysyłać listę commitów do osób odpowiedzialnych za to co się dzieje z takim artefaktem jak wydanie wersji później.
Historia jako narzędzie do debugowania
Drugie zastosowanie historii commitów jest dużo ciekawsze z punktu widzenia developera. Ile razy zachodziłeś w głowę dlaczego ktoś napisał kawałek kodu tak a nie inaczej? Dlaczego ktoś zrobił taki błąd? Czasem kawałek kodu potrafi być tak zagmatwany, że nie da się go zrozumieć, czasem tak głupio napisany, że aż niemożliwe, żeby autor napisał takie cudo na trzeźwo. Wtedy przychodzi na ratunek historia i opcja blame lub annotate (w zależności jakich narzędzi używasz). Ta opcja pozwala sprawdzić, kto ostatni dotykał każdej kolejnej linki w kodzie.
Blame i annotate
Dzięki temu bardzo szybko namierzymy osobę, która zostawiła kod w takim stanie. Warto zastanowić się, dlaczego kod został napisany tak a nie inaczej. Czasem wystarczy przeczytać commit message a czase trzeba zapytać osobę, która ostatnia go edytowała. Czasem dowiemy się, że kod powstał w jakiejś pomroczności i to jest po prostu zepsute ale czasem odkryjemy, że były jakieś ważne powód. Czasem to jakieś dziwne wymaganie klienta a czasem dziwne zachowanie frameworka czy biblioteki. Pewnie ktoś stwierdzi, że można wtedy zostawić komentarz – ale komentarze mają tą brzydką cechę, że gniją a bądźmy szczerzy, kto refaktoryzuje komentarze – to się nie sprawdza.
Do czego jeszcze może się przydać historia?
A choćby do tego, aby raz na jakiś czas pooglądać kod z lotu ptaka i zobaczyć ile pracy i energii włożyliśmy w stworzenie aplikacji puszczając na całym repozytorium narzędzie gource które pięknie wizualizuje kolejne commity w czasie – warto wybrać się w taką wycieczkę.
A Tobie do czego jeszcze przydaje się historia commitów w Twoim repozytorium?
