Git- magiczne zakl臋cia


IT, IT-DLA-ZIELONYCH / 艣roda, 23 pa藕dziernika, 2019

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? 馃槈

Dodaj komentarz

Tw贸j adres e-mail nie zostanie opublikowany. Wymagane pola s膮 oznaczone *