303Ostatnimi czasy mam delikatną zajawkę na system kontroli wersji GIT. Nie chodzi o to, że dopiero co o nim usłyszałem i się nie „jaram”. Znam go w podstawowym stopniu od dłuższego czasu. Jednak dopiero teraz kiedy zacząłem go używać w pracy widzę jakie to potężne narzędzie. Z tego powodu ten i kolejny wpis będą mu poświęcone.

System kontroli wersji GIT, z tego co zauważam hasając wesoło po polach internetu, ma raczej opinię systemu używanego do synchronizacji pracy w grupie osób. Niesłusznie. Dzisiaj przedstawię Wam 5 powodów, dla których warto zacząć stosować GITa pracując samemu. Czy to nad projektem studenckim czy też projektem „do szuflady”.

Zaczynamy

1. Możliwość łatwego cofnięcia katastrofy

W pierwszym punkcie zaczynamy od oczywistej oczywistości. Ile razy pracując nad kodem wykonałeś serię zmian, które w ostatecznym rozrachunku okazały się tak destrukcyjne, że odgruzowanie tego co zostało z aplikacji zajmie więcej czasu niż dodanie powyższych modyfikacji? Prawdopodobnie w amatorskich projektach zdarzyło Ci się to dosyć często. Gdybyś jednak trzymał swoje zmiany w repozytorium GITa, chociażby lokalnym, mógłbyś kilkoma kliknięciami usunąć to co niepotrzebnie dodałeś. Co więcej mógłbyś nawet wybrać część zmian do usunięcia lub usunąć zmiany wykonane jakiś czas temu bez naruszania tych najświeższych.

Jedyne wymaganie to naprawdę minimum dyscypliny i robienie commitów częściej niż na początku i na końcu projektu. Najłatwiej przyjąć zasadę, że commit powinien być na tyle mały, czy raczej monotematyczny, żeby można było go podsumować jednym, dwoma zdaniami.

2. Eksperymentowanie bez niszczenia

Kiedy Twój projekt istnieje dłużej niż 2 godziny zapewne jest zdatny do działania. Co więcej, jest szansa, że ktoś go nawet używa jeśli wysłałeś to jakiemuś znajomemu albo może nawet klientowi. Nagle w trakcie pracy zaczynasz się zastanawiać czy dodanie niewielkiej funkcjonalności będzie miało sens. W standardowym podejściu, kiedy kod jest po prostu trzymany na dysku w ostatecznej wersji nie masz za bardzo pola do eksperymentowania. Testowe dodanie jakiejś funkcji spowoduje w najlepszym wypadku konieczność jej żmudnego usuwania w przypadku kiedy okaże się ona niewypałem.

Mając repozytorium GITa możesz po prostu utworzyć nową gałąź z najnowszej (albo może nawet jakiejś poprzedniej jeśli jest taka potrzeba) wersji kodu i na niej eksperymentować. Nie udało się? Usuwasz gałąź. Funkcja okazała się strzałem w dziesiątkę? Po prostu wrzucasz zmiany do głównej gałęzi. Bez ryzyka. Jeśli jesteś niepewny to zostawiasz zmiany na osobnej gałęzi i w razie czego później podejmujesz decyzję co z nimi zrobić.

3. Łatwa praca z wielu miejsc

Masz stacjonarkę i laptopa albo zdarza Ci się coś robić na komputerze kolegi? Chcąc dodać jakąś poprawkę do aplikacji pisanej bez repozytorium musisz ją zawsze albo kopiować na dysk przenośny albo na dysk sieciowy. Potem trzeba pamiętać o zsynchronizowaniu się. Każde wyjście może oznaczać czasochłonne kopiowanie projektu, a te większe potrafią swoje ważyć.

W przypadku GITa wystarczy mieć lokalne repozytorium połączone z repozytorium zdalnym chociażby na GitHubie lub BitBuckecie. Zrobienie pusha do zdalnego repo to moment. Z resztą po chwili nauki GITa będziesz to pewnie robił automatycznie łącząc zmiany z różnych gałęzi. W następnym wpisie pokażę Ci nawet jak przy tym zachować ładną, liniową historię zmian. Zapomniałeś wrzucić ostatnich zmian? Możesz na drugim komputerze ugryźć inny kawałek aplikacji, który już jest wrzucony. Najwyżej potem kilkoma komendami złączysz zmiany. Nie marnuj czasu.

Ten podpunkt mógł się wydać trochę naciągany, ale liczę na Waszą wyobraźnię ;)

4. Łatwe włączenie nowych osób

Mówiłem, że dzisiaj opiszę przypadek pracy samodzielnej nad aplikacją. Chociaż nagłówek sugeruje inaczej to ten punkt nie odbiega za bardzo od założeń. Wyobraź sobie, że pracujesz nad swoim projektem i trafiłeś na problem, którego nie możesz rozwiązać. Piszesz do kolegi z pytaniem czy mógłby pomóc. Możesz mu albo wysłać cały projekt, albo bardzo dokładnie opisać na czym problem polega i liczyć, że coś podpowie. Oba rozwiązania są takie sobie.

Trzymając swój kod w repozytorium połączonym z repozytorium zdalnym po prostu wysyłasz koledze odpowiedni link i ewentualnie dajesz uprawnienia do przeglądania projektu. On nawet z poziomu przeglądarki ma możliwość szybko rzucić okiem na całość, Co więcej dzięki historii zmian może zobaczyć czy przypadkiem któraś z Twoich ostatnich zmian nie jest winowajcą. A jeśli kolega ma dobry dzień i większą chęć do pomocy to sam ma możliwość dodania commitów ze zmianami. Nie musi w dodatku tego robić na głównej gałęzi. Wystarczy, że utworzy nową gałąź zdalną dzięki czemu będziesz mógł przetestować to co Ci podsunął bez modyfikacji głównej historii.

5. Dwie pieczenie na jednym ogniu

Trzymając projekt w repozytorium możesz w trakcie szukania pracy upiec dwie pieczenie na jednym ogniu. Jednocześnie masz projekt do wpisania w CV i możesz zademonstrować, że w praktyczny sposób znasz GITa, który jest często używany w firmach. Pracodawca raczej nie będzie przeglądał repo, ale jeśli akurat trafisz na takiego co spojrzy to masz plus ;) Dodatkowo zyskujesz kolejny atut – jesteś wstępnie gotowy do pracy w zespole. Nawet jeśli wrzucałeś zmiany tylko Ty to jednak przechodziłeś przez całą ścieżkę łączenia tych zmian z różnych gałęzi. Być może masz też za sobą rozwiązywanie drobnych problemów czy konfliktów z repozytorium więc w nowej pracy nie będziesz musiał do każdej czynności wołać kogoś innego – raczej dotyczy to osób zaczynających pracę, ale na tym blogu jest Was pewnie spora grupa.

 

Kiedy już Wam powiedziałem jakie jest 5 zalet trzymania własnego kodu w repozytorium GITa liczę, że zaczniecie to robić. Mimo, że początkowo narzut może wydawać się duży (robienie commitów, wrzucanie zmian, pamiętanie, żeby regularnie commitować to co się zmienia) to po krótkim czasie na pewno docenicie takie podejście.

A jeśli ktoś jeszcze nie zna GITa to może zerknąć na jego oficjalny tutorial.