Rozumiejąc filozofię Gita i najważniejsze zagadnienia dobierzesz efektywne rozwiązanie do swojej sytuacji

Znajomość filozofii Gita i podstawowych zagadnień jest bardzo ważna do optymalnej pracy.

Git to system kontroli wersji (ang. version control system - VCS), to oczywiste. Niestety sposób, w jaki w nim pracujemy, już taki oczywisty nie jest.

Commitujemy lokalnie

Wydaje mi się, że większość osób stawiających pierwsze kroki w naszej branży, o VCS myśli w sposób scentralizowany - dokonuję zmiany w kodzie i zapisuję ją we wspólnym dla wszystkich repozytorium kodu.

W Gicie i każdym innym zdecentralizowanym systemie kontroli wersji oczywiście zapisujemy zmiany kodu (commity) w repozytorium, ale nie współdzielonym. Commitujemy do naszego własnego repo, znajdującego się na naszym prywatnym komputerze. I jest to różnica znacząca.

Synchronizujemy repozytoria

Dlaczego ma to takie znaczenie? Ponieważ w Gicie gdy udostępniamy innym programistom nasze zmiany, to nie wysyłamy pojedynczego diffa plików. To, co robimy w Gicie, to synchronizowanie między sobą dwóch niezależnych repozytoriów.

Zazwyczaj jest tak, że podczas naszej pracy, gdy commitowaliśmy lokalnie, ktoś inny również commitował i zdążył już swoje commity wypchnąć do Gitowego repo współdzielonego przez wszystkich. Wówczas nasza synchronizacja nie polega na zwykłym wypchnięciu naszych commitów - najpierw musimy ujednolicić stan naszego repozytorium, ze stanem ze zdalnego repozytorium, żeby wypychane commity pasowały, a repozytoria pozostały spójne.

Dbamy nie tylko o schludny kod, ale również o schludne repozytorium

Co więcej, nasza praca jako programistów, nie musi, a nawet nie powinna, ograniczać się tylko do zatwierdzania zmian w kodzie. Oprócz dbania o czysty kod powinniśmy dbać również o czyste repozytorium. Zanim zsynchronizujemy swoje repozytrium z innymi, powinniśmy zadbać o to, że to, co udostępniamy, jest schludne i czytelne. Historia commitów powinna umożliwić osobom trzecim (i nam samym w przyszłości) zrozumienie kontekstu naszej pracy i powodów powstania poszczególnych zmian. Rzut oka na tytuły commitów powinien dać obraz pracy, która była wykonywana.

W scentralizowanym systemie kontroli wersji moment wysłania zmian w kodzie do repo jest momentem finalnym naszej pracy, jest to moment udostępnienia zmian innym programistom. Jest to moment, w uproszczeniu mówiąc, nieodwracalny, to co wysłaliśmy, już nie zmienimy.

W zdecentralizowanym systemie kontroli wersji moment wysłania zmian w kodzie do repo odbywa się w trakcie naszej pracy, a momentem finalnym jest (mówiąc w uproszczeniu) synchronizowanie swojego repozytorium ze zdalnym repozytorium (jednym lub więcej). Wcześniej wielokrotnie wysyłaliśmy zmiany do repo (tworzyliśmy commity), na bieżąco dbając o czystość naszego repozytorium, czyli mówiąc konkretniej, poprawiając historię commitów, którą tworzymy. A jeżeli w trakcie pracy zostawiliśmy coś do posprzątania później, to przed opublikowaniem - sprzątamy. Synchronizujemy swoją historię commitów z innymi, dopiero gdy kod, który dopisaliśmy jest schludny i nasz wkład w repo projektu - tak samo.

Do dbania o schludność repozytorium służy wiele poleceń i dobrych praktyk niebędących tematem tego artykułu, ale warto odnotować, że kluczowe polecenia na ten temat to reset i rebase interactive, opisane w innym poście.

Rozgałęziamy się - branche

W Gicie każdego dnia (wielokrotnie) korzystamy z możliwości rozgałęziania historii commitów, czyli tworzenia tak zwanych branchy. Dzięki temu możemy nie tylko dobudowywać nasze (i cudze) repozytorium o nowe commity. Możemy to robić różnymi ścieżkami. Temat ten szerzej opisuję w poście dedykowanym branchom w Gicie, w tym miejscu jednak chciałbym zwrócić uwagę, że skoro jest to kolejny sposób, w jaki modyfikujemy nasze (i cudze) repozytorium, to również powinniśmy to robić schludnie. Bardzo łatwo poprzez zaniedbanie stworzyć historię trudną do przyszłych inwestygacji - doprowadzić do tak zwanego Git guitar hero:

Z tematyką branchy wiąże się wiele poleceń i rozwiązań, np. cherry-pick do ‘podkradania’ commita/commitów z innego brancha, czy wspomniane wcześniej rebase lub merge.

Zrozumienie filozofii Gita a wpływ na codzienną pracę

Przed oswojeniem się z zasadą działania zdecentralizowanego VCS, naturalne jest, że do repo próbuje się po prostu dosyłać nowe zmiany i nie myśli się o niczym więcej. Oczywiście takie podejście do pracy jest możliwe, a nawet wiele tooli do niego zachęca, oferując jeden magiczny przycisk, który wystarczy kliknąć i efekt pracy po prostu jest udostępniany innym - jakoś, nie wiedząc jak.

Niestety ta niewiedza ma swoją cenę:

• Po pierwsze, niemal zawsze przy takim podejściu tworzy się bałagan w historii, co w przyszłości odbija się np. trudniejszym inwestygowaniem przy debugowaniu jakiegoś problemu, albo głowieniem, dlaczego coś zostało zaimplementowane tak, a nie inaczej.
• Po drugie, przy takim podejściu nie wykorzystuje się pełnego potencjału Gita, np. jako narzędzia usprawniającego nam codzienną pracę.

Podsumowanie

Podsumowując: w Gicie nie ograniczamy się do commitowania zmian w kodzie. W Gicie jednocześnie (świadomie lub nieświadomie) administrujemy całym repozytorium, które regularnie synchronizujemy z innymi. Powinniśmy dbać o to, aby to, co zobaczą inni, było schludne i czytelne, aby w przyszłości można było z łatwością do tego wrócić.

Jeżeli masz pytania, nie wahaj się zadać je w komentarzu lub napisać do mnie maila. Oczywiście zachęcam również do naszych szkoleń z Gita (i nie tylko Gita), na których w fajnej atmosferze ćwiczymy na różnym poziomie zaawansowania, zarówno dla programistów, ale również np. dla wdrożeniowców czy testerów :)