System Kontroli Wersji
8 godz. 23 min · Git · Full-stack i Programowanie
Mateusz KuleszaSenior Software Developer, Konsultant, TrenerInne systemy wersjonowania wymagają konfiguracji specjalnych serwerów - a z GIT wystarczy do tego twój komputer. GIT pozwoli Ci zapisywać kolejne wersje twojej pracy lub eksperymentować z różnymi zmianami. Jeśli chcesz tworzyć kopie zapasowe - w kursie zobaczysz jak tworzyć klony twojego projektu oraz jak wysyłać i pobierać aktualne zmiany pomiędzy klonami.Pierwsza sekcja pozwoli Ci zyskać pewność w samodzielnej pracy z GITem nim podejmiesz się pracy w zespole. Dowiesz się jak przygotować zestaw zmian, ignorować pliki tymczasowe, jak tworzyć migawki z opisami zmian, a następnie przeglądać i porównywać zmiany dokonane nawet miesiące temu. W kolejnej części kursu dowiesz się jak wycofywać zmiany, przywracać wcześniejsze wersje i edytować historię zmian. Zobaczysz, że w GIT “nic nie ginie”. Pokażę Ci jak możesz odzyskać pozornie utracone zmiany oraz jak naprawić historię zmian łącząc, dzieląc, a nawet zmieniając kolejność dokonanych wcześniej zmian.
Jesteś w trakcie pracy nad ważnym projektem, i nagle musisz oderwać się od pracy, by wykonać jedną, szybką poprawkę? W GIT możesz błyskawicznie przełączyć się na inną wersje projektu, lub po prostu “odłożyć na później” pliki nad którymi pracujesz i wrócić do nich kiedy tylko tego potrzebujesz. W tej części kursu zobaczysz jak pracować na gałęziach, dodawać etykiety oraz przełączać różne wersje plików. Dowiesz się jak porównywać oraz eksperymentować z plikami bez ryzyka utraty danych. Co najważniejsze - nauczysz się łączyć i dzielić wiele różnych wersji twojej pracy. Zobaczysz, jak praca na gałęziach nie tylko zwiększy Twoją swobodę i elastyczność w codziennej pracy, ale również jak gałęzie pozwalają wielu osobom na równoległą pracę na tych samych plikach bez martwienia się o utratę danych lub niespójne wersje.
W kursie dowiesz się nie tylko jak zapamiętywać zmiany, ale także jak je opisywać i oznaczać, tak, by nawet miesiące później móc łatwo odnaleźć odpowiednią wersję pliku, lub by dowiedzieć się kiedy, kto i dlaczego zmieniał dany plik. Zobaczysz jak dobre praktyki w opisywaniu zmian wspomagają pracę grupową. Dowiesz się jak pobrać lub wysłać zestaw zmian na serwer oraz jak połączyć zmiany swoje, lub zmiany otrzymane od współpracownika. Dodatkowo, zobaczysz jak bezpiecznie rozwiązać problem konfllktujących zmian w plikach lub jak przenieść zmiany z wersji do wersji. W kursie dowiesz się także jak w bardzo prosty sposób korzystać z pozornie najtrudniejszej funkcji GITa, jaką jest polecenie “rebase”. Zobaczysz jak usprawni się Twoja praca, gdy będziesz mógł w jednym kroku zbudować historię zmian. Jeśli źle zapisałeś zmiany, nie podoba Ci się historia zmian, lub po prostu chciałbyś łatwo uniknąć konfliktów - git rebase będzie Twoim nowym ulubionym narzędziem.
…zmieniło ten sam plik, trzeba jakoś te zmiany połączyć. Zobaczysz jak GIT pozwala wysłać zestaw zmian na serwer, pobrać zmiany innych osób i automatycznie dołączyć te zmiany w odpowiednich miejscach. Co jednak jeśli dwie osoby zmienią tę samą linię w pliku? W kursie dowiesz się nie tylko jakie są różne sposoby i strategie łączenia zmian, ale także jak dzięki historii będziesz wiedział dlaczego zmiana w pliku została wprowadzona. Dzięki narzędziu rebase będziesz mógł zaaplikować wszystkie zmiany w odpowiedniej kolejności i w odpowiednim miejscu.
W kursie poznasz także usługę GitHub. GitHub to nie tylko usługa udostępniająca repozytoria dla GIT - umożliwia również tzw. społecznościowe podejście do tworzenia… I to nie tylko kodu. Zobaczysz, że dzięki GitHub praca nad kodem aplikacji czy nową książką może odbywać się zespołowo. Pokażemy Ci jak publikować swoje zmiany oraz jak zgłaszać je innym do przejrzenia i połączenia z ich wersją. Poznasz także sposoby planowania pracy, przydzielania zadań i zarządzania postępem ich wykonania - wszystko na twoim koncie na portalu GitHub. Oprócz poleceń i funkcji GIT w tym kursie pokażemy Ci również, na prostych, praktycznych przykładach, typowe techniki i praktyki pracy z GIT. Podczas kursu symulujemy zespół budujący prostą stronę internetową. Co ważne, nie musisz znać HTML by skorzystać z tej części kursu! Zobaczysz jak wygląda praca z perspektywy jednej osoby, co zrobić gdy musisz przerwać pracę i przełączyć się na inne zadanie oraz jak przygotować Twoją pracę do podzielenia się nią z zespołem. Pokażemy kilka przykładów organizacji pracy. Zobaczysz prace z małym, centralnym repozytorium, a także modele pracy rozproszonej, z której korzystają duże projekty typu open-source. GIT to branżowy standard, który obowiązuje praktycznie we wszystkich firmach zajmujących się tworzeniem aplikacji lub stron internetowych. Sprawia to, że wiedza, którą zdobędziesz po przerobieniu tego kursu, bezpośrednio przełoży się na efektywność Twojej pracy oraz projekty, które tworzysz.
Kurs przygotowany został z myślą o wszystkich, którzy chcą nauczyć się najbardziej popularnego i elastycznego systemu kontroli wersji i wykorzystać go do efektywnej pracy w zespole, jak i na potrzeby indywidualnych projektów. Jest również przeznaczony dla każdego, kto pracuje z kodem źródłowym i chciałby nie tylko tego, by jego zmiany były bezpieczne, ale by jednocześnie mieć swobodę pracy na kilku równoległych wersjach kodu oraz móc swobodnie eksperymentować nie bojąc się o utratę danych. Jeśli chciałbyś dowiedzieć się jak sprawnie korzystać z Githuba oraz zrozumieć, czemu ten system jest tak chętnie stosowany przez programistów na całym świecie - to najlepsza metoda!
W poprzedniej lekcji udało nam się nasz nowy nagłówek czyli osobną gałąź ze zmianami właśnie w nagłówku
połączyć w naszej głównej gałęzi master i dzięki temu jak tutaj zajrzymy do naszego pliku.
Zmiany z tych obu gałęzi są połączone.
Tutaj zarówno zmiany ze spisu treści które jak pamiętasz były dokonane metodą fast forward czy przesunięcie
wskaźnika do przodu do nowych zmian jak i tutaj ten drugi merge nagłówka który już wymagał osobnego
commita.
Jedno i drugie stało się automatycznie git sam wiedział w którym miejscu umieścić zmiany jak połączyć te pliki
ze sobą i efekt końcowy.
Jak widać jest ok i wszystko jest na swoim miejscu.
Jednak nie zawsze tak się dzieje.
Zdarzają się przypadki gdy zmiany w plikach zmiany na różnych gałęziach nie można po prostu w łatwy sposób
automatyczny zintegrować.
Git musi zatrzymać i poprosić nas o pomoc i każda taka sytuacja gdy mamy dwa różne pliki i nie można
ich łatwo zintegrować jest nazywana po prostu konfliktem i wtedy git właśnie pokaże ci jak można w łatwy
sposób rozwiązać konflikty w Git.
O ile w twojej codziennej pracy konflikty w Twoich plikach konflikty w gałęziach są raczej czymś czego
chciałbyś unikać.
Tak tym razem pokażę ci jak stworzyć taki konflikt byś wiedział w jakich sytuacjach on powstaje co jest
jego powodem a następnie pokaże ci jak go rozwiązać.
Zacznijmy od zmiany tego pliku naszego indeks HTML.
Jednak żeby powstał konflikt będziemy musieli go zmienić jednocześnie na dwóch gałęziach może nie jednocześnie
może po kolei.
Więc zacznijmy od zmiany w tym pliku na gałęzi master.
Powiedzmy że tutaj w naszym spisie treści dodam jeszcze dodatkowa gałąź l.
Ul.
I dodam jeszcze jakieś powiedzmy podtytuły. Niech będzie to pierwszy commit podobnie jak nazwy lekcji.
Dodam tutaj jeszcze jakiś podtytuł poprawiamy commit.
I jeszcze jedno poprawiamy.
Praca z indeksem skopiuję sobie to będziemy używali tego za chwilkę.
I mamy jedną zmianę i powrócę do wiersza poleceń oczywiście git status pokaże mi niezapisany plik zapiszemy
plik i git status pokaże mi że właśnie że mam jeden zmodyfikowany plik więc standardowo jak już wiesz git add dodajemy
plik git commit spis treści i powiedzmy podtytuły praca lokalna i tutaj nagle będzie master dodałem jeszcze
jeden commit czyli nasz spis treści pod tytułem praca lokalna znajduje się tu i teraz aby powstał konflikt.
Ktoś musiałby zmienić dokładnie ten sam plik w tych samych liniach lub w liniach nachodzących na siebie.
Może być to ktoś inny.
Mógł być to nawet ja jeśli zmienię to na innej gałęzi czyli przejdźmy do git checkout i powiedzmy spis
treści.
Log tutaj wygląda to tak jak widzisz nasze zmiany zniknęły dlatego jesteśmy na innej gałęzi gdzie jeszcze tych
zmian nie było.
Pozwolę sobie wkleić dokładnie te same zmiany.
Nie udało się.
Nie szkodzi to zrobimy jeszcze raz ale tym razem wprowadzę tutaj inną treść czyli powiedzmy dodawanie zmian
co tu jeszcze będzie przywracanie
wersji.
Dodajmy jeszcze jedno dodam tutaj jeszcze powiedzmy edycja historii czyli zwróć uwagę że zmieniłem
dokładnie ten sam plik.
Zmieniłem te same linie lub linie które nachodzą się i teraz będę miał dwie wersje tego samego pliku i obie
będą równoważne.
Nie będzie można je połączyć nie niszcząc struktury żadnego z nich.
Trzeba będzie zdecydować które z tych elementów chcemy oraz w jakiej kolejności dlatego że one są dokładnie
na tych samych liniach.
Stworzę tutaj też commit git status.
Zwróć uwagę że teraz jestem na gałęzi spis treści czyli modyfikuje zupełnie inną historię niż przed
chwilą na gałęzi master git add.
Podobnie git commit dodam teraz wiadomość.
Spis treści praca lokalna
alternatywna czyli żeby była tutaj różnica.
Który commit jest który i teraz tak przejdę z powrotem do mastera
mamy tutaj naszą poprzednią listę czyli pierwszy poprawny commit pracy z indeksem i teraz chciałbym
połączyć te dwie gałęzie czyli chciałbym gałąź tą spis treści połączyć z naszą gałęzią master jak pamiętasz
poleceniem git diff mógłbym
porównać dwie gałęzie.
Czyli mogę robić git diff spis treści.
No i widzimy tutaj różnicę między tymi plikami i jesteśmy troszeczkę do przodu bo oczywiście w naszej gałęzi
master mam już zmieniony nagłówek w spisie treści jeszcze nie.
Tutaj mamy też jakieś zmiany od nas zmienione style.
Natomiast tutaj w środku widzimy te zmiany które wykonaliśmy przed chwilą czyli mamy tutaj nasze zmiany czyli
pierwszy commit no i mamy tutaj zmiany z tego z tej gałęzi spis treści i w tych samych liniach mamy różnice.
I tutaj jak widzisz on próbuje tutaj plusy i minusy czyli w tym momencie gdybyśmy po prostu pobrali te zmiany właśnie
byśmy zaaplikowali nasze zmiany na spis treści byśmy zupełnie utracili te linijki.
Zobaczmy co się stanie gdy spróbujemy wykonać git merge czyli ja tutaj wyczyszczę i git merge.
Podaję znowu nazwę gałęzi którą chce do naszej gałęzi zaaplikować którą chce dołączyć czyli będzie to
spis treści.
I tym razem widzisz nie poszło tak gładko.
Nie połączyło nam się automatycznie.
Mam informacje conflict content i merge conflict w pliku indeks HTML.
Mam też informację że automatyczny merge nie udział mamy tutaj failed i prośba fix conflicts.
Then commit the result czyli tutaj warto czytać informację mam krok po kroku co się stało i co mamy zrobić.
Mamy przejrzeć pliki plik index HTML mamy zobaczyć jakie konflikty wystąpiły poprawić je a następnie
po prostu git commit czyli scommitować rezultat i zobaczmy jak wygląda nasz plik index html przejdę do edytora.
I tutaj jak widzisz pojawiły się dodatkowe symbole takie strzałki w jedną stronę strzałki w drugą stronę
i znaki równa się tutaj fajnie bo ten edytor akurat bardzo ładnie podświetla znajduje te wszystkie symbole.
Nie każdy edytor będzie to kolorował niektóre edytory pokażą to jeszcze fajniej na przykład pokażą to w osobnych kolumnach
po prawej stronie zmiany jedne po lewej drugie to wszystko zależy od edytora tutaj akurat to w ten sposób.
I faktycznie jedyne co ten git robi to po prostu dodaje te linijki do pliku w każdym miejscu takich miejsc
może być kilka.
Gdzie zostały wprowadzone zmiany po obu stronach.
Jak widzisz tutaj nie musiałby git nic poprawić bo ok.
Nie musiałby też naszych styli poprawiać.
Bo wszystko też było w porządku tam wpasowało tu natomiast w indeksie były dwie różne zmiany w tym samym w tym
samym miejscu tak w tych liniach i w tych liniach mamy kilka opcji.
Wystarczy.
Pierwszą opcją najpopularniejszą najczęstszą jest ręczna modyfikacja czyli mogę to pousuwać.
To co bym nie chcę zostawić to co chce wprowadzać zmiany po prostu doprowadzić ten plik index HTML do takiego
stanu jaki chciałbym żeby był faktycznie w mojej historii.
Nim jednak to zrobimy.
Chcę ci pokazać i jeszcze jedną opcję mianowicie tutaj korzystając z git checkout mogę taki konflikt
rozwiązać.
No bardzo nieładnie bo po prostu mogę wybrać którąś z tych opcji.
Tutaj u góry jak widzisz z gałęzi head czyli master na której byliśmy czyli to są nasze zmiany.
Zmiany które mieliśmy na branchu na którym jesteśmy natomiast tutaj jest spis treści to są zmiany z gałęzi
z branchy które chcieliśmy dołączyć.
Więc to są czyjeś zmiany w sensie nie z naszej gałęzi teraz poleceniem git checkout powiedzmy ours albo theirs
Możesz zdecydować czy chcesz czyjeś zestawić nasze odrzucić zmiany lub nasze zostawić czyjeś odrzucić
tu akurat w odwrotnej kolejności spróbujmy być tutaj bardzo nieładnie niekoleżeńscy i po prostu zignorować
wszystkie inne zmiany i tylko przyjąć nasz jak się okazuje ścieżkę w pliku index HTML.
I tutaj wyobraźmy taką wersję gdzie tylko nasze zmiany przyjmujemy cały czas jesteśmy tutaj w trakcie
konfliktu
i tutaj też git status zobacz pokazuje że cały czas ten plik jest tutaj w konflikcie jest niezmerge'owany
i teraz gdybyśmy zrobili git add i git commit no to taki konflikt by się rozwiązał.
Powstałby nowy commit z wynikiem naszego merge'a i wszystko byłoby OK.
Tylko że no nie zawsze chcemy w ten sposób że tylko przyjmiemy nasze lub czyjeś zmiany.
Czasem żebyśmy faktycznie te zmiany mogli rozwiązać ręcznie gdy commit taki merge nie wyjdzie gdy coś się
popsuje zrobisz coś źle też nic straconego nigdy się nie przejmuj.
Nie można nic popsuć tak jak pamiętasz z poprzednich lekcji.
Możesz zawsze przywrócić poprzednią wersję możesz cofnąć commity a jeszcze prościej po prostu
polecenie git merge abort
możesz przerwać.
Jak widzisz bieżący merge i git posprząta przywróci wszystkie zmiany do stanu w jakim były.
Czyli jak widzisz tutaj wszystko jest tak samo jak było.
Możemy spróbować zrobić to jeszcze raz czyli jeszcze raz robię git merge spis treści i tym razem zrobimy
to prawidłowo.
Nie będę usuwał czyiś zmian nie usuwał swoich zmian tylko postaram się je połączyć.
Po pierwsze musisz usunąć wskaźniki te które wskazują na to że jest konflikt i powiedzmy że połączę wszystkie
razem ze sobą w ten sposób ok usunę spis treści i niby wszystko ok ale jeszcze muszę się przyczepić że kolejność jest
nie tak.
Więc zróbmy może w ten sposób żeby ten spis treści miał sens dodawanie zmian pierwszy commit pracę
z indeksem ok.
Ma to sens.
Powiedzmy że taki spis treści nas zadowala że jest to jakiś sposób na połączenie tych dwóch bez usuwania
niczego ja teraz zapisze plik index HTML git status dalej jest unmerged robię git add index i to jest po prostu
to jak widzisz jest informacja git commit jeszcze raz zrobimy sobie git status changes to be commited i gdy wszystkie konflikty
rozwiązane ale jeszcze jesteśmy w trakcie merge'owania wystarczy pliki git add dodać i już nie musimy podawać
żadnej wiadomości żadnej opcji wystarczy dodać git commit
i tutaj automatycznie też pojawia się tak jak poprzednio tak tworzymy nowy merge commit możemy dać mu
tutaj dodatkowy message.
Mogę dopisać powiedzmy połączono spisy treści escape w i q.
W tym przypadku.
I teraz jak zobaczę sobie git log
to daleko został git.
No to mamy połączone spisy treści merge branch powstał nowy commit który powstał właśnie w wyniku rozwiązania
konfliktu.
I tutaj nasz spis treści jest teraz zawiera zmiany z obu gałęzi i na naszej stronie jak widzisz elegancko
także pojawiły się wszystkie podtytuły z obu gałęzi.
Czyli jak widzisz masz różne sposoby łączenia tych gałęzi.
Pamiętaj że gdy jest konflikt nie przejmuj się możesz go bardzo łatwo rozwiązać a nawet gdy coś pójdzie
nie tak nie po Twojej myśli po prostu wypisujesz git merge abort.
Tak robiliśmy to wcześniej i to przywraca cię dokładnie do momentu sprzed mergeowania i możesz twój merge
wykonać jeszcze raz tym razem w inny sposób.
Aż w końcu się uda.
Merge'owanie jest bardzo ważne dlatego że w kolejnych następnych lekcjach będziemy zajmować się współpracą
współpracą grupową i wtedy często będzie się zdarzało że wiele osób będzie modyfikowało te same pliki i trzeba będzie
te pliki łączyć.
W większości przypadków będzie to przebiegało bez problemu chociaż będą też nierzadko zdarzały się przypadki gdy
dwie osoby zmienią ten sam plik w dokładnie tych samych liniach.
No i będzie konflikt który na szczęście już wiesz jak bezproblemowo rozwiązać.
Jeśli chodzi o git merge to zobaczysz jeszcze jeden sposób mianowicie git z rebase'm ale o tym już w kolejnych
lekcjach.
Do zobaczenia.