Jakub Raczkowski 
Kontynuujemy naszą naukę narzędzi/technologii siedzących w Javie oraz dookoła niej. Ostatnim razem zajmowaliśmy się Mavenem, bez którego trudno wyobrazić sobie jakikolwiek javowy projekt. Z Gitem jest podobnie, ale bardziej – bez niego trudno sobie wyobrazić JAKIKOLWIEK projekt.
Uwaga! W tej serii zajmuję się opisowym przedstawieniem tematu, a celem jest zapoznanie z zagadnieniem w sposób luźny i zrozumiały dla nowicjusza. W związku z tym wiele elementów siłą rzeczy musi zostać pominiętych. Tych z was, którzy chcieliby się dowiedzieć więcej, zapraszam do źródeł na końcu artykułu.
Początek obecnego millenium. Właśnie wróciliście ze szkoły i najchętniej od razu ruszylibyście do kompa by raz-dwa odpalić drugie Diablo, gdzie na poziomie trudności „piekło” i w trybie „hardcore” jesteście gotowi aby w końcu stawić czoła Mefisto, bossowi trzeciego aktu. Nikt z waszych kolegów z klasy nie dotarł jeszcze tak daleko!
No, ale matka z mokrą szmatą budzi większą grozę niż sam Pan Nienawiści, zatem wpierw idziecie odrobić lekcje.
Mija kwadrans… drugi… trzeci… Powoli zbliża się godzina 18:00. Ćwiczenia z matmy już zapisane, druga forma angielskich czasowników zakuta na blachę, jeszcze tylko narysować tę mapkę na gegrę i będzie można pyknąć w diabełka!
Wtem do pokoju nieśmiało wchodzi młodszy brat. Patrząc w podłogę, cicho wymawia słowa po których nic już nigdy nie będzie takie samo:
– Co było problemem w powyższej historyjce? Kto wie?
Otóż to! Obaj bracia grali na tym samym sejwie przez co weszli sobie w paradę i problem jednego stał się automatycznie problemem tego drugiego. W skrócie: nastąpił
KONFLIKT
Taka sytuacja nie jest jedynie domeną gier, może dotknąć wielu branż, a w szczególności tych trudniących się rozwojem oprogramowania. Jeszcze pal licho, jak pracuje tam jedna, dwie, może trzy osoby, w dodatku tuż obok siebie – wtedy komunikacja działa wzorowo i każdy wie co ma robić oraz których fragmentów kodu nie powinien dotykać. Jednakże, w sytuacji gdy zespół się rozrasta, szansa na konflikty rośnie diametralnie.
Aby temu zaradzić wymyślono programy typu VCS (Version Control System) takie jak Subversion (SVN), które jednak nie były idealne – działały raczej wolno, miały problemy z rozwiązywaniem konfliktów, a na domiar złego wymagały centralnego serwera i połączenia z Internetem (wtedy to jeszcze nie było tak oczywiste jak teraz).
Gdzieś w tym samym czasie młody Linus Torvalds, student helsinskiego uniwerku, aktywnie rozwijał swoje najnowsze dziecko: Linuxa, tego pierwszego i oryginalnego. Z początku był jedynym programistą w projekcie, ale równocześnie ze zdobywaniem popularności przez ten świeży OS, pojawiali się kolejni koderzy chcący stać się częścią projektu i zaistnieć w historii jako ojcowie założyciele Linuxa.
Pomagali jak mogli, poświęcali swój czas prywatny łatając błędy i dodając nowe funkcjonalności. A tymczasem biedny Linus musiał to wszystko ogarniać samodzielnie: aktualizować, kopiować, przenosić, usuwać… W końcu nie wytrzymał i wykrzyknął frazę zarezerwowaną dotychczas jedynie dla bohaterek kina ślizganego:
Ludzie, stop! Tak nie można, żeby wszyscy na raz! Tu trzeba ustalić jakieś zasady!
Na bazie powyższego narodził się Git, którego twórcą jest właśnie Torvalds. W teorii: prosty programik odpalany z konsoli i robiący zapisy aktualnemu stanowi kodu projektu. Ale właśnie dzięki swojej prostocie okazał się „game changerem” i do dziś znajduje się w niezbędniku każdego programisty.
Zatem, co ten Git potrafi?
- z jego pomocą możemy tworzyć tzw. „commity” czyli zapisy stanu kodu projektu w dowolnym momencie, do każdego commita można szybko wracać i przeglądać zmiany
- nazwy owych commitów są bardzo istotne, to dzięki nim możemy prześledzić kompletną historię projektu – od zera do gotowej aplikacji
- pozwala na „rozgałęzianie” (ang. branching) projektu, przez co nad tym samym kodem mogą pracować różni programiści, pomaga w rozwiązywaniu konfliktów
- daje wsparcie zewnętrzym repozytoriom takim jak GitHub lub GitLab dzięki którym można pokazać swój kod dowolnej osobie
Tutaj warto zaznaczyć, podkreślić, pokolorować, strzelić z liścia i zasadzić kopa, aby zapamiętane zostało, że:
GIT I GITHUB TO NIE TO SAMO!
Lepiej! Można zarówno korzystać z Gita nie korzystając z GitHuba jak i na odwrót!
I w tym właśnie miejscu chciałbym płynnie przejść do tego jak zacząć używać GitHuba jeszcze nawet nie dotykając samego Gita.
Ideą GH jest to, że jest takim dyskiem, gdzie każdy może założyć osobisty profil i wrzucić własną pracę albo podejrzeć kod innych programistów. Takie przesłanie kodu może nastąpić oczywiście za pomocą jednej z komend Gita (wpisanej w konsoli albo puszczonej kliknięciem z poziomu IntelliJ), ale równie dobrze możemy po prostu „zuploadować” swój plik z poziomu strony www GitHuba.
Wracając na chwilę jeszcze do Mavena – mimo, że jest niezbędny w pracy z projektami to tak na dobrą sprawę jego ogarnięcie możemy odwlekać aż do chwili kiedy zabierzemy się za swój pierwszy samodzielny projekt. Z Gitem jest inaczej.
Kiedy już napiszemy swój pierwszy „Hello world!”, porobimy trochę ćwiczeń na takich stronach jak Hackerrank, Codewars czy Codegym i mamy tę świadomość, że programowanie jest tym co chcemy robić w życu…
…wtedy jest już ten moment kiedy należy zacząć korzystać z GitHuba*
(*) Lub GitLaba, który oferuje zbliżoną funkcjonalność. Rożnice leżą w detalach i kwestiach prawnych – np. GitHub to obecnie platforma Microsoftu, podczas gdy GitLab to projekt Open Source i każdy może sobie założyć własny serwer.
Są co najmniej 3 powody dlaczego warto się za to zabrać:
- „Kwadraciki” – nasze commity są obrazowane przez kwadraciki w naszym kalendarzu, który osoba z zewnątrz może sobie podejrzeć. Lubią tak robić rekruterzy, którzy sprawdzają czy jesteśmy aktywnymi programistami.
- Obycie z Gitem – jeśli zaczniemy się bawić tym narzędziem już na początku nauki, to kiedy ogarniemy podstawy języka równocześnie będziemy zaznajomieni z systemem kontroli wersji.
- Schowek – pewne elementy kodu warto sobie zachować na później aby móc na szybko do nich wracać jeśli czegoś zapomnimy. GitHub/Lab jest idealnym miejscem na taki schowek.
Tym bardziej, że wrzucenie swojego pliku z kodem jest banalnie proste (na przykładzie GitHuba):
Tylko tyle i aż tyle!
Praca z samym Gitem ze wsparciem IntelliJ też nie należy do szczególnie uciążliwych i z reguły sprowadza się do operowania kilkoma kolorowymi ikonkami na górnym panelu.
Na koniec pragnę jeszcze pokazać jak podłączyć swój projekt do GitHuba, z użyciem IntelliJ IDEA. Tutaj mamy właściwie dwie możliwości:
- Albo właśnie stworzyliśmy nowy projekt i chcemy go wrzucić na swoje konto GitHub.
- Albo mamy już jakiś projekt na GitHubie (swój albo cudzy, bez znaczenia) i chcemy go ściągnąć, a następnie otworzyć u siebie.
W pierwszej sytuacji musimy wpierw połączyć IDE z GitHubem. Wchodzimy w ustawienia, wyszukujemy „GitHub” i klikamy „+” aby dodać nowe konto. Logujemy się za pomocą naszego profilu GH lub tymczasowego tokenu (też wydanego przez GH). Następnie szukamy na górnym panelu zakładki „Git”, klikamy „GitHub” i wybieramy opcję „Share project on GitHub”. Tam zakładamy nowe repozytorium, potwierdzamy i gotowe.
Druga opcja jest jeszcze łatwiejsza – wystarczy wejść na pożądany projekt na stronie GH, kliknąć zielony przycisk „<> Code” i skopiować link do repozytorium. Teraz przechodzimy do IntelliJ i klikamy tak jak chcielibyśmy utworzyć nowy projekt, ale wybieramy opcję: „Project from version control”. Wklejamy skopiowany wcześniej link, potwierdzamy, czekamy chwilę aż się wszystko pobierze i gotowe.
Ok, myślę, że na początek wiedza o Gicie zawarta w tym wpisie powinna wam całkowicie wystarczyć, choć to zaledwie czubek góry lodowej. Nic nie wspomnieliśmy o tym jak rozwiązywać konflikty, czy o innych niż commity sposobach interakcji (code review/pull request), ale ich nauką możecie śmiało poczekać do swojego pierwszego projektu grupowego.
Na koniec mogę wam jeszcze polecić parę dobrych źródeł do lepszego poznania Gita i jego funkcjonalności:
Prosty i krótki kurs Gita (ANG).
Kompletny kurs Gita w formie video na YT (POL)
Dziękuję za uwagę i zapraszam za kilka dni do następnego odcinka w którym omówimy podstawy baz danych SQL i NoSQL.
