Kliknąłeś w wilka brawo !

W programowaniu system kontroli wersji jest niezbędnym narzędziem dla każdego dewelopera. Nie ma znaczenia czy mówimy o frontendzie lub backendzie. Więcej, pamiętajmy, że każdy kto obcuje z kodem jest wręcz skazany na posiadane umiejętności pracy z system do zarządzania nim. Zatem testerzy czy devopsi również na co dzień używają tego typu oprogramowania. Pracując w Javie, C# czy tworząc kod w JavaScripcie lub nawet będąc bazdanowcem – wszędzie używane jest jakieś narzędzie do zarządzania tworzonym kodem. Obok języka angielskiego, jest to drugi element świata IT, o którym wielu zapomina, a który jest niezbędnym składnikiem każdego projektu.

System kontroli wersji to w zasadzie narzędzie wspomagające pracę przy tworzeniu oprogramowania. Dodajmy jasno – niezbędne narzędzie! Pozwala ono na swobodne śledzenie zmian w kodzie z pełną historią zmian, z możliwością tworzenia rozgałęzień (branch) i ich scalania (merge). Uzyskujemy także zarządzanie dostępem do różnych branchy, a także możliwość pełnego odtworzenia projektu z wcześniejszych prac. W poniższym wpisie przedstawiony zostanie jeden z bardziej popularnych (a większość zapewne powie, że najbardziej popularny) systemów do kontroli wersji jakim jest Git.
Jak to z tym Gitem było…

Sam Git jest dość młody w tym segmencie rynku. Stworzony został w 2005 roku i jest przykładem na to, że potrzeba jest matką wynalazku. Wiąże się z nim „romantyczna” historia, związana bezpośrednio z Linuksem i pracami nad nim. Otóż w roku 2005 twórca BitKeeper, narzędzia do kontroli wersji, używanego przez osoby rozwijające Linuksa, obwieścił iż jego oprogramowanie nie będzie już w pełni darmowe. W tym momencie twórcy Linuksa, z Linusem Torvaldsem na czele, postanowili stworzyć własne oprogramowanie do zarządzania kontrolą wersji, które będzie posiadać zalety BitKeepera, a jednocześnie mieć całkowicie otwarty kod. W ten sposób powstał Git, który szybko zyskał na popularności. Ironią losu jest tutaj to, iż finalnie, w roku 2016, BitKeeper stał się otwartym oprogramowaniem, wielu twierdzi jednak, że o wiele lat za późno, aby móc stać się tak popularnym jak młodszy konkurent od Torvaldsa.

Git to zdecentralizowany system kontroli wersji. Zatem w przeciwieństwem do wielu starszych systemów, opartych na architekturze scentralizowanej, nie wymaga on połączenia z serwerem. Co za tym idzie, każdy z deweloperów może pracować lokalnie, bez ciągłego połączenia z zewnętrznym głównym serwerem. Oczywiście powstaje wiele rozszerzeń do Gita, które posiadają główny serwer z kodem, ale służy on wówczas do kontroli dostępu z wieloma ułatwieniami przy scalaniu kodu i jego inspekcji poprzez interfejs www. Na pewno wielu z was korzysta lub chociaż słyszało o GitHubie lub GitLabie, które to właśnie oferują tego typu usługi.

Git w stosunku do wielu starszych rozwiązań jest znacznie szybszy i świetnie przystosowany do pracy z plikami tekstowymi, na których de facto opiera się programowanie. Pozwala on także na swobodną pracę offline, a także szybkie i bezproblemowe scalanie kodu. Co ważne, kontrola wersji nie odbywa się poprzez pracę tylko na różnicowych danych, ale na zrzutach migawek. Zatem zapisując aktualne zmiany, zapisujemy stan całego projektu. W celu optymalizacji niezmodyfikowane pliki nie są zapisywane, ale posiadają referencje do wcześniejszej, identycznej wersji. Pozwala to na swobodą i szybką realizację rozgałęzień kodu (branchy).
Co daje nam Git?

Pracując z Gitem warto przedstawić podstawowe pojęcia, jakie są używane podczas pracy z tym oprogramowanym, a jakie już zostały nadmienione we wstępie:

- repozytorium – miejsce na zbiór z kodem, w większości przypadków znajduje się tutaj jeden większy projekt; repozytoriom może być ono lokalne, ale także zdalne; najczęściej dokonuje się synchronizacji repozytorium głównego (zdalnego) i lokalnego, jako iż repozytorium lokalne jest kopią repozytorium zdalnego

- branch – rozgałęzienie w kodzie w obrębie repozytorium, pozwala to na jednoczesną prace w kodzie wielu osobom, często branche robione są per element/funkcjonalność w tworzonym oprogramowaniu

- commit – zatwierdzenie i wysłanie zmian w kodzie do repozytorium lokalnego

- push – wysłanie commitów z lokalnego repozytorium do repozytorium zdalnego

- pull – pobranie zmian (commitów) z repozytorium zewnętrznego do lokalnego

- fetch – pobranie zmian (commitów) z repozytorium zewnętrznego do lokalnego, jednakże w przeciwieństwie do pull, nie nanosi zmian, a daje podgląd zmian jakie zostały naniesione przez innych na zdalnym repozytorium

- merge– łącznie kilku branchy, często niesie to za sobą rozwiązywanie wielu konfliktów, z racji wykonanych zmian w tym samym miejscu.

Praca z Gitem najczęściej sprowadza się do: sklonowania repozytorium zewnętrznego do jego lokalnego odpowiednika. Następnie przenosimy się na żądanego brancha lub tworzymy nowego z już istniejącego. Po naniesieniu zmian w kodzie tworzymy commita. Wówczas zaciągamy zmiany z zewnętrznego repozytorium. Oczywiście rozwiązujemy konflikty, jeśli takowe się pojawią. W kolejnym kroku wrzucamy własne zmiany lokalne na zewnętrzne repozytorium. Tak najczęściej wygląda praca z Gitem przy tworzeniu oprogramowania.
Git: terminal vs narzędzie graficzne

Git pozwala na wykonywanie powyższych poleceń bezpośrednio z terminalu, co ważne Git jest narzędziem multiplatformowym. Możemy używać go na Linuxie, Windowsie czy macOS. Dobrze jest znać polecenia Gita, chociażby te podstawowe. W większości przypadków przedstawionych powyżej schemat pracy z Gitem jest znacznie prostszy jeśli używamy nakładki graficznej na terminal Gita. Pozwala ona na wygodniejszą pracę w większych projektach. W znacznie prostszy i przyjemniejszy sposób nie tylko wrzucimy nasz kod do repozytorium, ale także przejrzymy zmiany, sprawdzimy historię, zrobimy merga czy przeniesiemy commity pomiędzy branchami. Oczywiście zapewne jest wiele osób, które nie wyobrażają sobie pracy z Gitem w aplikacji z GUI, ale kontrola wersji ma być narzędziem w pracy z którego będziemy mogli korzystać wygodnie. Więcej, ma ono być niemalże przezroczyste dla dewelopera, takim niezbędnikiem, który nie sprawa, że praca z kodem staje się męczarnią. Oczywiście większość zaawansowanych działań na repozytorium wymaga użycia terminala (co jest faktem), aczkolwiek zdarza się to rzadko i na co dzień narzędzie graficzne dla większość osób będą znacznie przyjemniejsze w pracy.

Jeśli chodzi o wybór narzędzia z Gui do pracy, to w tym przypadku wybór jest bardzo szeroki. Z darmowych narzędzi warto wymienić: Git Extensions, SourceTree czy TortoiseGit. Również wiele IDE, w których tworzony jest kod, posiada podstawową integrację z Gitem. Praktycznie każdy znajdzie coś dla siebie. Szeroką listę narzędzi znajdziemy na stronie Gita: https://git-scm.com/downloads/guis/ .
Git flow

Na koniec wprowadzenia do Gita zostawiłem pojęcie Git flow, które nie jest obce każdemu kto pracuje z Gitem, nawet na mniejszych projektach. Git flow określa sposób pracy z branchami. Pozwala to na spójną, równoległą i niekonfliktową pracę z podziałem na kilka głównych branchy.

Develop – pierwszym podstawowym branchem jest develop, czyli gałąź na którą wrzucane są nowe funkcjonalności, które już zostały przetestowane; jest to podstawowy branch, z którego powstają kolejne branche w przypadku, gdy tworzona jest kolejna funkcjonalność

Feauture – są to branche powstałe z developa, tworzone w celu powstania nowej funkcjonalności (często naprawa błędu to finalnie, tworzenie nowej funkcjonalności, ehh…), kod na tych gałęziach bywa w większość przypadków niestabilny; po zakończeniu prac nad nowymi elementami na branchu feature jest on mergowany do brancha develop

Master – branch będący odzwierciedleniem produkcji, określa on aktualny stan produkcji

Realease – branche powstałe z developa, są to gałęzie, które przygotowują kod (stabilizacja) do wdrożenia nowej wersji na produkcję, finalnie takie branche trafiają po wdrożeniu na developa i mastera

Hotfix – grupa branchy, które powstają z mastera i naprawiają najbardziej palące błędy na produkcji; po zakończeniu testów, branch trafia na produkcję (merge do mastera) i na developa.

Takie rozdzielenie branchy sprawia, że zarządzanie kodem, nowymi funkcjonalnościami, naprawą błędów i nowymi wersjami na produkcji jest znacznie prostsze i wydajniejsze. Pozwala to także, na lepsze zarządzanie zasobami ludzkimi.

Git – niezbędne narzędzie przy tworzeniu oprogramowania

Wszędzie tam, gdzie jest tworzony kod, tam pojawia się system kontroli wersji. Nie ma znaczenia w czym piszemy i gdzie. Zawsze nasza praca musi zostać dostarczona do repozytorium, które to pozwoli na wspólną pracę w zespole. Ba, nawet tworząc chałupniczy projekt w pojedynkę, system kontroli wersji pomoże nam w zapanowaniu nad kodem.

Git to obecnie jeden z popularniejszych narzędzi do zarządzania kodem. Jego znajomość jest równie ważna jak język programowania, w którym będziemy pisali oprogramowanie. Mimo, że jest to narzędzie działające w tle, to praca z nim jest szybka i przyjemna. Lata doświadczeń w innych systemach wersji sprawił, że Git jest obecnie wręcz synonimem kontroli wersji. Jest potrzebny w pracy programisty, na równi ze znajomością języka angielskiego. Praca na co dzień w narzędziu graficznym do Gita to dobry sposób na podstawową obsługę Gita dla większości zadań z jakimi spotykają się osoby pracujące nad projektem IT (a z takimi najczęściej mamy kontakt).

Git z potrzeby chwili stał się narzędziem, które stało się wiodącym graczem na rynku. Zostało stworzone od samych podstaw przez deweloperów dla deweloperów, co widać w pracy z nim na co dzień. Szybkość, łatwość pracy i duże możliwości sprawiają, że jest on niezbędnym elementem w pracy każdego dewelopera.