Praktyczny kurs GIT dla zielonych cz. 5 – Dobre praktyki i podsumowanie

Tak oto po miesiącu produkowania się na temat podstaw Git’a, dochodzimy do zakończenia kursu. W ostatnim artykule z tej serii chciałbym wspomnieć nieco o dobrych praktykach, związanych z często popełnianymi błędami. Podsumuję również krótko cały kurs i wskażę ewentualne kroki dla głodnych dalszej wiedzy (jeśli takowi się znajdą).

Dobre praktyki

Git, jak każdy elastyczny i na wiele pozwalający system, ma dużo zalet. Z jego użytkowaniem wiąże się jednak pewna odpowiedzialność. Wystarczy jeden commit zrobiony „na odwal się”, który można by poprawić przed spushowaniem w kilkanaście/kilkadziesiąt sekund, a problemy z niego wynikające mogą odbić się minutami ,lub nawet godzinami poświęconymi na naprawę w późniejszym czasie. Z tego powodu w ostatniej części kursu postanowiłem zebrać w jednym miejscu zasady i zalecenia odnośnie prowadzenia repozytoriów Git.

Dodaj niepotrzebne pliki do .gitignore

Zajmie to dosłownie minutę, lub jej ułamek, a może zaoszczędzić potężnych konfliktów w przyszłości. Przykładem niepotrzebnych śmieci są pliki konfiguracyjne środowiska. Za każdym włączeniem programu lubią się modyfikować w tle. Kiedy dwie różne osoby zaczną pracować na repozytorium, konflikty, których można było uniknąć, będą rosnąć szybciej, niż grzyby po deszczu.

Sprawdzaj pliki w stage’u przed commitem

Często do commita wpadają pliki, których nie powinno tam być. Bywa też, że zrobimy zmiany w plikach tylko dla testów, a potem zapomnimy ich przywrócić do stanu początkowego. Warto sprawdzić jakie pliki będą w commicie komendą git status, aby chociaż pobieżnie sprawdzić czy wszystko jest ok. Pół biedy jak szybko zlokalizujemy pomyłkę. Gorzej jeśli niechciane zmiany dadzą boleśnie o sobie znać po jakimś czasie.

Twórz małe, dobrze opisane i częste commity

Warto rozdzielić zmiany na jak najmniejsze, szczególnie gdy pracujemy nad skomplikowaną funkcjonalnością. Primo, pozwoli to szybko namierzyć odpowiedni commit i podejrzeć zmiany. Secundo, w przypadku problemów z projektem i cofaniem się do ostatniego commita będą mniejsze straty.

Nie commituj nie działającego kodu

Wyobraźmy sobie repozytorium jako grę, a commity jako popularne tzw. checkpointy. Nie chcielibyśmy żeby nasz checkpoint był zepsuty i trzeba było cofać się jeszcze dalej w przypadku „śmierci”. W Gicie działa podobna zasada. Dodatkowym utrudniem analizy historii kodu będzie zdarzenie, kiedy kilka commitów po sobie będzie zmieniać ten sam obszar tego samego pliku.

Uzgodnij zasady z innymi użytkownikami repozytorium

Warto dogadać się co do nazewnictwa branchy i sposobu opisywania commitów. Jeśli każdy będzie uprawiał samowolkę, w bardzo szybkim czasie powstanie taki bałagan, że będzie ciężko się połapać w tym, co jest gdzie i dlaczego.

Rozdziel funkcje/poprawki na branche

Gdy rozwijana aplikacja rośnie, warto rozdzielić zmiany na osobne gałęzie. Trzeba wrzucić np. patch 1.3? Napisz go w brancnhu patch/1.3. Przycisk na stronie głównej nie działa? Stwórz poprawkę w branchu fix/main-website-button. Chcesz dodać przykładowo funkcję komentowania dla użytkowników aplikacji? Branch feature/user-comments będzie odpowiedni. Repozytorium prowadzone w taki sposób znacznie zyskuje na przejrzystości.

Ogranicz ilość plików binarnych w repozytorium

Z racji faktu, że git umie rozpoznawać i przechowywać wyłącznie zmiany plików tekstowych, nie powinno się wrzucać plików binarnych. Po pierwsze, zajmują dużo miejsca, a repozytoria powinny być możliwie lekkie i szybkie w pobieraniu/wysyłaniu. Po drugie każda zmiana w pliku binarnym (nawet najmniejsza, jeden bajt) wiąże się z przesyłaniem całego pliku w repozytorium od nowa. Po trzecie, konflikty plików binarnych są problematyczne w rozwiązywaniu. Wreszcie, nie ma możliwości podglądu plików binarnych w repozytorium zdalnym z poziomu przeglądarki (z wyjątkiem obrazków i czasami filmów). W związku z tym wszelkie binarne pliki które nie są integralną i stałą częścią aplikacji (czyli np. nie będące grafikami przycisków czy innymi modeli graficznymi) powinny być trzymane poza repozytorium. Niechciane pliki można wyeliminować z repozytorium np. za pomocą .gitignore.

Co zostało omówione w tym kursie?

Przeszliśmy od wyjaśnienia na analogicznym i nieco abstrakcyjnym przykładzie czym jest repozytorium git, przez instalację, dokładny opis czym jest stage, commitowanie, branchowanie, aż po mergowanie i pull requesty. Synchronizacja plików z repozytorium zdalnym nie powinna być problemem. Dowiedzieliśmy się co to jest .gitignore, jak powinno się tagować aplikacje, oraz co warto robić, a czego lepiej nie robić. W przypadku konfliktów, będziemy umieli je samodzielnie rozwiązać. Zrozumienie i przetrenowanie rzeczy opisanych w tym kursie jest w pełni wystarczające do codziennej pracy, a dodatkowe funkcje, które są wbudowane w git, przydają się już nieco rzadziej. Poza codziennym prowadzeniem własnych projektów, gita używa się coraz częściej w pracy związanej z programowaniem, dlatego umiejętność ta jest ceniona w powiązanych z kodzeniem środowiskach.

Co dalej?

Dla głodnych dalszej wiedzy proponuję książkę Pro Git dostępną za darmo, online w języku angielskim. W języku polskim warto natomiast przejrzeć nie tak obszerną, pierwszą edycję tej samej książki. Alternatywnie do czytania książek polecam po prostu zapoznać się z dostępnymi poleceniami, które doskonale są opisane w języku angielskim w dokumentacji git-scm.