Cześć ! 🙂 Dzisiaj opowiemy sobie o kilku komendach Gita, które bardzo często możecie usłyszeć z ust programistów. Brzmią one we wszystkich językach świata brzmiące podobnie, nieustannie bardzo po angielsku.

W ostatnim artykule wspominałam o bardzo ważnej koncepcji dwóch wersji repozytorium – tej lokalnej i tej znajdującej się na serwerze. Determinuje to cały proces korzystania z Gita.

Jeśli wolicie wideo, posłuchajcie artykułu tutaj:

Commit i Push

Aby zapisać wprowadzone zmiany w repozytorium programiści muszą je zcommitować, wykonać commit’a, czyli właśnie utrwalić aktualny stan aplikacji jako snaphot/migawkę. Dzięki commit’owi stan ten zapisywany jest lokalnie na komputerze programisty w programie Git.

Repozytorium na serwerze jednak nic o tym nie wie. Dopiero po wypushowaniu zmian (zrobieniu push’a) są one zapisywane również na serwerze.

Commit i push będziecie więc dziś kojarzyć z zapisywaniem zmian.

Fetch i Pull

Co jednak, jeśli chcielibyśmy sprawdzić, czy na serwerze są jakieś nowe zmiany lub też pobrać zmiany wprowadzone na serwerze przez innych programistów? Wtedy przyda się fetch i pull. Komenda Git fetch daje programiście informację, czy wersja repozytorium na serwerze zawiera jakieś nowe zmiany. Na przykład możemy się dowiedzieć, że na branch’u X pojawiły się dwa nowe commity. Oznacza to, że nasz lokalny branch X nie jest aktualny- brakuje mu właśnie tych dwóch commit’ów. Sama komenda git fetch nie pobiera jednak zmian. Aby je pobrać lokalnie musimy użyć komendy git pull, a więc innymi słowy zpullować zmiany.

Odtąd, gdy usłyszysz, że ktoś nie zrobił pull’a, pomyśl- nie pobrał zmian, nie ma aktualnego stanu aplikacji z serwera.

Mergowanie i konflikty

W ostatniej części poświęconej systemom kontroli wersji wspominałam o branch’ach, których w Git-cie możemy utworzyć bardzo dużo. Niejednokrotnie istnieje więc potrzeba, aby je połączyć. W tym celu mergujemy. W trakcie merge’a coś, czego nigdy nie życzą sobie programiści, to wystąpienie konfliktów. Co to oznacza? To sytuacja, w której przy łączeniu dwóch branch’y, a więc dwóch wersji naszej aplikacji, okazuje się, że jedno i to samo miejsce zostało w różny sposób zmodyfikowane w obydwu wersjach. Wtedy Git nie wie, co zrobić, którą wersję przejąć. To tak, jakbyście chcieli połączyć dwie wersje dokumentu tekstowego, gdzie w obu akapit numer 2 został w innych sposób zmodyfikowany. Wówczas programista musi sam zdecydować, co chce przejąć do wersji końcowej- jedną z tych wersji, a może obydwie? To podejmowanie decyzji w trakcie mergowania nazywamy rozwiązywaniem konfliktów.

Na dziś to już wszystko, poznaliście najważniejsze komendy Git’a. Czy teraz poniższa instrukcja ewakuacji dla programisty również Was śmieszy? 😉