Praktyczny kurs GIT dla zielonych cz. 1 – instalacja i podstawy działania

Podstawowe pojęcia

Wyobraźmy sobie, że chcemy zbudować budynek z klocków (np. Lego) na potrzeby jakiejś wystawy. W takiej sytuacji musielibyśmy przychodzić regularnie do określonego pokoju, gdzie przechowujemy wszystkie nasze klocki i tam rozwijać nasz projekt. Żeby nie robić bałaganu w całym pokoju (na komputerze), warto by przechowywać wszystkie nasze klocki w jakimś pudełku czy innej przestrzeni ograniczonej. Nazwijmy tę przestrzeń określeniem repozytorium. Dzięki temu, kiedy chcemy przenieść naszą budowlę z jednego pomieszczenia do innego (z jednego komputera na inny), wystarczy przenieść nasze pudełko (repozytorium lokalne, czyli takie na którym pracujemy na co dzień), w którym trzymamy klocki.

Wyobraźmy sobie teraz, że zbudowaliśmy nasz budynek, wystawiliśmy gdzieś na wystawie (w repozytorium zdalnym do którego ewentualnie mamy dostęp) i wszyscy podziwiają jaki jest wspaniały. Co jednak, kiedy chcielibyśmy dobudować drugi budynek obok, połączony z pierwszym np. mostem.

Nie będziemy przecież na wystawie, na oczach wszystkich siedzieć i dobudowywać kolejne elementy projektu. Istnieje wszak możliwość, że coś uszkodzimy uszkadzając przy okazji również pierwszy budynek. W takim przypadku można szybko skopiować nasz aktualny projekt, w naszym repozytorium lokalnym  i pracować na jego kopii. Jeśli dokonamy zmiany, którą uznamy po czasie za błąd, zawsze możemy wrócić do oryginalnego projektu i zobaczyć jak to było zrobione. Takie różne równoległe wersje tego samego projektu (branch – z ang. gałąź) mogą znajdować się w naszym repozytorium niezależnie od siebie, w dowolnym stadium rozwoju. Kiedy skończymy nasz budynek możemy wprowadzić nasze zmiany na wystawie (w repozytorium zdalnym) za jednym razem.

Wyobraźmy sobie, że budujemy nasz drugi budynek w spokoju, a tu przychodzi zarządca wystawy i mówi: słuchaj, budynek jest ważny ale parking obok tego budynku jeszcze ważniejszy dlatego, najpierw zrób parking. Dla nas to już nie problem, gdyż możemy zostawić tymczasowo naszą gałąź (branch) projektu, związaną z budową drugiego budynku. Następnie od głównej gałęzi (nazwijmy ją master branch) zawierającej wyłącznie pierwszy budynek robimy nową gałąź, na której będziemy dobudowywać parking. W takim wypadku realizacja obu zadań będzie wyglądała mniej więcej tak:

Budowa naszego projektu może zająć wiele dni i zostać podzielona na różne etapy (commity). Dla przykładu tworzenie parkingu możemy podzielić na: przygotowywanie terenu, ogradzanie terenu, tworzenie nawierzchni, oznaczanie miejsc… Załóżmy że każdy fakt wprowadzenia konkretnej porcji zmian wykonując dany etap produkcji (commit), będziemy zapisywać na kartce (będzie zapamiętywał git). Daje nam to kilka zasadniczych zalet. Najważniejszą z nich jest fakt, że jeśli coś zepsujemy w takim stopniu, że nie potrafimy tego szybko odwrócić, zawsze możemy cofnąć się (revert) do wcześniej zapisanego etapu (commita), który jeszcze działał. Ponadto, notowanie wprowadzania poszczególnych zmian w projekcie (commitów), przydaje się do późniejszej jego analizy. Dzięki temu możemy się domyślić przyczyn wprowadzania takich, a nie innych zmian, ponieważ każdy commit powinien posiadać krótki opis (description).

Teraz coś o wprowadzaniu zmian. W naszej pełnej akcji i grozy historii poruszyliśmy temat repozytoriów zdalnych i lokalnychRepozytorium lokalne to nasza przestrzeń na której pracujemy na co dzień. Repozytorium zdalne służy do przechowywania naszego projektu gdzieś (w internetach), skąd można pobrać go sobie ściągnąć (clone – sklonować) i pracować dalej już na lokalnym.

Do czego w naszej historii zabrakło to kwestia magicznej synchronizacji zmian pomiędzy lokalnymi repozytoriami. Za pierwszym razem gdy dołączamy do istniejącego projektu możemy sobie sklonować całe repozytorium zdalne. Potem już tylko synchronizujemy poszczególne branche (gałęzie). Synchronizacja może działać w dwie strony. Za pomocą pusha „wypychamy” nasze commity do repozytorium zdalnego. Analogicznie możemy „pociągnąć” zmiany w odwrotną stronę za pomocą komendy pull.

Czyli że niby co?

Pogrubiony tekst wyjaśnia jak dana sytuacja/rzecz ma się do samego Gita. Podkreślone zwroty natomiast, są to określenia stosowane stricte w pracy z Gitem. Większość z nich to słowa kluczowe i zarazem komendy konsolowe jak commit, push, pull czy clone. Mam nadzieję że mój wywód choć trochę rozjaśnił podstawy mechaniki działania Git’a. Zapewne tak się nie stało, dlatego zawsze można doczytać co robi poszczególna komenda, np. tu. Kluczowym jest jednak zrozumienie, co to jest branch, repozytorium czy commity gdyż bez tych określeń ciężko rozmawiać o czymkolwiek w tym temacie. Dalej jest już tylko żonglowanie w mniejszym, lub większym stopniu na przemian tymi samymi określeniami z rzadka dodając nowe. W następnej części poradnika będę opisywał dokładniej działanie powyższych, jak i innych komend. Będę też starał się przedstawić kroki jakie trzeba podjąć w konkretnych scenariuszach. Także tego… stay tuned! 🙂