To nie jest poradnik jak używać Git'a. Do tego powstało wiele poradników, wpisów oraz pytań na StackOverflow. Również sama dokumentacja jest pomocna o ile wiemy czego szukać. I w tym tkwi największy problem dla osoby początkującej. Dlatego ten wpis chciałbym poświęcić pewnym określeniom jakie się spotyka w pracy podczas korzystania z Gita'a. Chciałbym aby był on swego rodzaju słownikiem pojęć dla osób początkujących, który pozwoli się oswoić z istniejącą terminologią.
Na początku jest Git
Jednak zanim przejdę do samych pojęć to krótkie przypomnienie na temat samego Git'a. Jest to rozproszony system kontroli wersji stworzony przez autora Linuksa - Linusa Torvaldsa. Został stworzony w 2005 roku jako narzędzie potrzebne do rozwoju kodu systemu operacyjnego autora. Aktualna wersja to 2.13, która została wydana 10 maja tego roku. Korzystamy z niego dzięki różnych serwisów internetowych, z których najpopularniejsze to Github i Bitbucket.
Fork
Jest to jedna z najprostszych funkcji wyżej wymienionych serwisów. dzięki forka możemy sobie stworzyć prywatną kopię repozytorium, które nas interesuje. Dzięki temu możemy się bawić, ulepszać oraz przerabiać je nie bojąc się, iż coś zepsujemy w oryginalnym. Tutaj jeżeli coś zepsujemy to możemy po prostu usunąć prywatną kopię i jeszcze raz zrobić forka. Gorąco zachęcam do korzystania z tego rozwiązania.
PullRequest
Kolejna opcja, którą dają nam te serwisy to Pull Requesty. Jest to funkcja, którą pokochają (lub nie) młodzi programiści. Polega to na tym iż zanim dodamy jakiś kod do gałęzi, z których są potem budowane aplikacje (np. develop dla serwera testowego lub master dla produkcji) powinniśmy go dać do recenzji. Nasz kod zwykle dajemy do recenzji osobom, z którymi pracujemy w projekcie - najczęściej tych bardziej doświadczonych lub na podobnym poziomie. Dzięki recenzji można wyłapać część błędów jakie można popełnić podczas pisania np.: zostawiony console.log() lub dump(). Bardzo często też można wyłapać złe formatowanie i pewne rzeczy w kodzie, które są jasne dla piszącego ale dla innych programistów już nie np.: mało znaczące nazwy funkcji, powtórzenia w kodzie, dziwne konstrukcje itd.. Opcja recenzji kodu pozwala utrzymać kod czystym oraz zwiększa jego jakość. Osoby początkujące pewnie dosyć często będą widzieć komentarze by poprawić kod lub użyć wbudowanej funkcji zamiast pisać swoją. Ale to jest dobry efekt uboczny i nie należy się go obawiać ponieważ w ten sposób można się wiele nauczyć a z czasem będzie tych komentarzy mniej a w związku z czym nasz kod będzie lepszy.
Gałęzie i merge
Cały git opiera się na tak zwanych gałęziach(branches). Pozwalają one kontrolować tworzenie nowych funkcjonalności, tworzenie alternatywnych rozwiązań czy testowanie innych podejść. Gdy chcemy stworzyć coś nowego to tworzymy osobną gałąź gdzie kod może sobie leżeć nie psując innych części programu. Najłatwiej to pokazać na prostym przykładzie. Załóżmy, iż w gałęzi master jest kod produkcyjny. To znaczy, iż jest on stabilny, działa i nie należy z nim eksperymentować. Jednak klient chce nowych funkcjonalności. Na pewno nie będziemy ich pisać na tej gałęzi. Dlaczego? Ponieważ istnieją przypadki losowe, które nas zmuszą do ponownego wgrania kodu na serwer a nie wgramy tam czegoś co dopiero jest tworzone i posiada błędy. Dlatego dużo lepszym rozwiązaniem jest stworzenie nowej gałęzi na podstawie aktualnego mastera. Dzięki temu mamy niejako kopię naszego kodu i możemy go rozbudowywać o nową funkcjonalność. Kiedy będziemy mieli już ją gotową to możemy ją zmerdżować do głównej gałęzi. Spowoduje to dodanie nowopowstałych zmian do naszej głównej gałęzi. Przy odpowiednim prowadzeniu gałęzi Github może to zrobić za nas automatycznie podczas akceptacji PullRequest'a. jeżeli chcecie poczytać więcej na temat mergy to zerknijcie tutaj. Jest to dobrze opisanie i nie ma potrzeby powielania tego
Rebase (git rebase)
Rebase jest już poleceniem bardziej skomplikowanym oraz niebezpiecznym jeżeli się nie wie co robić. w uproszczeniu dzięki rebase'a możemy nałożyć nasze zmiany na górę dowolnej gałęzi czyli nasze zmiany będą tymi najnowszymi. Żeby to łatwiej zrozumieć krótki przykład. Załóżmy, iż tak jak w poprzednim przykładzie stworzyliśmy dla nowej funkcjonalności nową gałąź i na niej rozwijamy kod. Jednak w międzyczasie do mastera weszły poprawki. Możemy użyć wtedy rebase by zaktualizować naszą nową gałąź ale mieć nasze zmiany na samej górze. Gdzie jest haczyk? Ano w tym, iż wraz z rebasem trzeba skorzystać z push force ponieważ rebase zmienia historię drzewa. Może to sprawić, iż osoba która pracuje na tej samej gałęzi i wrzuci swoje zmiany straci je przez naszą operację. Dlatego moja rada dla początkujących jest następująca: Git rebase wykonuj tylko na swoim prywatnym forku mając pewność, iż nikt inny nie korzysta z gałęzi. Jaka pozostało wada tego rozwiązania? jeżeli podczas przechodzenia po drzewie git napotka konflikty to musimy je rozwiązać od razu. I jeżeli dawno nie aktualizowaliśmy gałęzi to może to być bardzo bolesne(wiem z doświadczenia). Dlatego kolejna rada: Jeśli masz zamiar robić rebase'a to rób go regularnie. Znowu na koniec zapraszam do dokumentacji, którą znajdziecie tutaj.
Interaktywny rebase (git rebase -i)
Jest to część polecenia rebase, które pozwala na manipulowanie zmianami. Korzystanie z tego polecenia pozwala nam między innymi na: usuwanie już wrzuconych na serwer zmian, zmianę nazwy comita lub też łączenie ze sobą comitów. Znów powrócę do przykładu z nową funkcjonalnością. Chwilę temu mówiłem o aktualizowaniu naszego brancha względem mastera. Teraz powiem o interaktywnym rebase w kontekście przygotowania do PullRequesta. Podczas tworzenia nowych rzeczy możemy tworzyć wiele śmieciowych comitów w postaci: work in progress, fix1, fix2 itd. Jest to jak najbardziej poprawne zachowanie ponieważ powinniśmy robić comity jak najczęściej ale zwykle nie chcemy wrzucać takiego bałaganu do mastera. Dlatego możemy wykorzystać interaktywny rebase i złożyć wszystkie comity do jednego dużego(squash) i go dopiero wrzucić do głównej gałęzi. Również możemy usunąć te comity które uważamy za niepotrzebne. Więcej na temat możliwości interaktywnego rebase'a możecie poczytac tutaj
Mam nadzieję, iż ten post pomoże osobom, które wchodzą w świat gita. Pisałem go z perspektywy osoby, która regularnie korzysta ze wszystkiego co zostało tutaj napisane. Jednak początki były trudne i nie zawsze wiedziałem co należy robić a do rebase'a podchodziłem z dużą rezerwą. Nie jest on straszny ale wymaga doświadczenia i pamiętania o dwóch zasadach, które napisałem. A jak u was wygląda zabawa z gitem. Robiliście coś więcej czy póki co tylko git commit git push? Pochwalcie się w komentarzach oraz piszcie jak wam się(i czy w ogóle) podobał wpis.
