Każdy kto pracuje z zespołami deweloperskimi musi rozumieć podstawy gita – nawet jeśli nie jest programistą. Dlaczego? Bo to integralna część procesu wytwarzania oprogramowania. Z tego tytułu zorganizowaliśmy wywiad, z autorem bloga Mergujmy, nikt nie woła!, Sebastianem. W wywiadzie odkrywamy kilka podstawowych pojęć związanych z gitem. Jakkolwiek sam wywiad Wam nie wystarczy, aby uznać, że rozumiecie podstawy, to liczymy na to, że dzięki niemu i dodatkowym materiałom oswoicie się z tym tematem i będziecie swobodniej go odkrywać dalej, na własną rękę. Gotowi?

Nie będziemy przedłużali, jedziemy od razu z pytaniami 🤠

Po co nam w ogóle git?

Świetne pytanie, może zacznę je na rekrutacjach zadawać! Git to trochę takie narzędzie podróży w czasie. Tak jak edytujesz jakiś dokument w Google Docs i nazywasz wersje i potem sprawdzasz różnice pomiędzy nimi, cofasz zmiany łatwo itp. Wyobraź sobie jak trudne by to było, gdybyś musiał wciskać control-z setki razy. Git zapewnia Ci wersjonowanie, historię edycji, porównywanie wersji i bezpieczne dodawanie zmian. 

Czym są branche?

Może pozostańmy przy porównaniu do dokumentów w Google Docs. W docsach możesz pracować w trybie edycji – to się robi najczęściej – lub w trybie sugerowania. W trybie sugerowania ustawiasz kursor w miejscu które chcesz zmienić i piszesz, ale trik polega na tym, że wydrukowany dokument nadal będzie w starej formie dopóki ktoś nie zaakceptuje Twojej poprawki. W kodzie aplikacji to wygląda podobnie. Robisz swój branch gdzie dodajesz zmiany, dajesz komuś do przejrzenia i jak wszystko jest akceptowalne to nakłada się to na główny branch.

Przybliż czytelnikom pojęcia master, develop, release branch itp. 

W gitcie możemy mieć niemal dowolną ilość branchy. Master branch jest (lub był do niedawna) domyślnym branchem w repozytorium, punktem który łączy wszystkie zmiany robione przez osoby pracujące nad repozytorium. Git jest zbiorem małych programów, które można używać na wiele sposobów. Stąd bierze się wiele sposobów na pracę w repozytorium. 

Najprostszym jest podejście, że mamy główny branch z którego wychodzą feature branche, które są mergowane do mastera i kod z mastera jest deployowany – udostępniany do klienta. 

Inne podejście, nieco bardziej skomplikowane, to posiadanie brancha develop, od którego rozpoczynają się feature branche i są do niego mergowane. Potem tworzy się release branch, czyli wersja kodu, którą chcemy deployować. Jak wszystko jest ok to release branch jest mergowany do mastera. 

Najważniejsze jest to, że nie ma najlepszego dla wszystkich flow. Jeden zespół będzie się dobrze odnajdywał z branchami develop, master, release i hotfix, a drugi nie będzie potrzebował tego wszystkiego i będzie leciał tylko na masterze. To chyba jest siłą gita, nie słyszałem by ktoś narzekał, że git go ogranicza lub na coś nie pozwala.

Mamy jeszcze inne dwa pojęcia: konflikt i merdżowanie. O co w tym chodzi?

O tym mergowaniu już trochę powiedziałem. Łączy się to mocno z pojęciem code review, czyli wzajemnej inspekcji kodu wśród programistów. Jeśli jest ok, to jest to branch jest mergowany. Czasem bywa, że w dwóch osobnych branchach zmieniany jest ten sam kawałek kodu i gdy pierwszy branch zostanie zmergowany do mastera to drugi nie może być zmergowany ponieważ zmiana koliduje z tym co właśnie zostało dodane do mastera. Wtedy trzeba ten konflikt rozwiązać, ale raczej nie jest to częsta sytuacja.

To co to jest gitlab albo github? 

Oba te serwisy dostarczają nieco narzędzi, które obudowują gita. Narzędzie do code review: jest. Łatwe i przyjemne dla oka przeglądanie historii: jest. Estetyczne wyświetlanie różnic między wersjami: jest

Bez github.com, git pewnie nie stałby się tak popularny jak jest w tej chwili. To był przełom w 2007 roku. Znakomita większość projektów open source jest tam hostowana, chyba każda firma ma swoje konto na github.com.

O gitlab nie mogę Ci wiele powiedzieć, bo nie używałem go od 6 lat. 

Jakie są dla nich alternatywy?

Jest bitbucket od Atlassiana (to firma stojąca za Jira ;)), Amazon Web Services też oferuje code hosting – CodeCommit. Pojawia się również coraz więcej serwisów analizujących przepływ pracy w repozytorium, by lepiej zrozumieć pracę zespołu, zlokalizować wąskie gardła.

Znasz jakieś fajne sposoby na zrozumienie gita? Co byś polecił osobom, które chciałyby go zrozumieć, a dopiero zaczynają przygodę z programowaniem albo po prostu chcą poszerzyć swoją wiedzę?

Założyć konto na github.com – to może być dobry początek. Jest tam masa dokumentacji. Ale i bez tego można lokalnie rozpocząć repozytorium i nawet na prostych plikach tekstowych poćwiczyć. Ja właśnie poznawałem działanie git na takim lokalnym repozytorium. Zawsze można ściągnąć sobie jakieś repozytorium z githuba i poćwiczyć część poleceń w ten sposób. Szczególnie te stojące za porównywaniem wersji, przeszukiwaniem historii itp. Gdzie lepiej mieć repozytorium z długą historią. 


Kilka słów o Sebastianie

Sebastian Nowak – programista od 2007 roku, z doświadczeniem w branżach e-Marketing, e-Commerce i Travel. Mocno wierzy w zwinne metodyki pracy, lean i promuje skupienie na wartości dla użytkownika. Od 2015 roku walczy o sprawiedliwość dla podróżnych pod sztandarem AirHelp. Od dwóch lat Software Engineering Manager tamże.

🤩 Zapraszamy na blog Sebastiana – Mergujmy, nikt nie woła! oraz na jego profil na Linkedin.


Dodatkowe materiały o gicie

https://training.github.com/ – tzw. “Cheat Sheets” i trochę pojęć
https://git-scm.com/book/en/v2 – oficjalna dokumentacja w formie książki “Pro Git”
https://www.katacoda.com/courses/git – interaktywny, bezpłatny, kurs – razem z piaskownicą :)
https://learngitbranching.js.org/ – uczymy się gita za pomocą “gry”

Dodaj komentarz