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 sekcji kursu pracowaliśmy na jednej gałęzi i była to gałąź master.
W kolejnych lekcjach pokażę ci jak pracować równolegle na kilku wersjach twoich plików właśnie z wykorzystaniem
gałęzi.
Jednak jeszcze nim przejdziemy do gałęzi chciałbym ci pokazać.
Jedno bardzo przydatne polecenie jakim jest git.
Tag. Git tag.
Pozwoli dodać tzw. etykiety czyli zapamiętać sobie jakiś commit pod nazwą którą podamy.
I tutaj utworzyłem sobie nowy zupełnie projekt.
Pierwsza strona git log jak widzisz są tu jakieś zmiany i powiedzmy że chciałbym zapamiętać jakiś moment
w czasie.
Do tego właśnie świetnie przydaje się git tag jak pamiętasz z poprzednich lekcji historię możemy modyfikować.
Czyli ja mogę wycofać się z tych commitów i dodać zupełnie nowy początek tej historii ale także jak pamiętasz
Zmieniając historię.
Można tutaj bardzo łatwo zagubić te commity i wyszukiwanie tych commitów przy użyciu polecenia git reflog
może być nie tylko czasochłonne ale faktycznie możemy pewne rzeczy zgubić.
Dlatego warto sobie zachować jakieś referencje.
Jak pamiętasz.
Head jest referencją do commita na którym właśnie w tym momencie jesteśmy.
Master jest referencją do głównej gałęzi na której pracowaliśmy.
Ale oprócz tego przy użyciu polecenia git tag mogę stworzyć dodatkowe referencje dodatkowe etykiety
żeby nie zgubić commitów.
I jeśli wykonam git tag w ten sposób to on po prostu wyśle tam listę tagów.
W tym momencie jak widzisz nie mamy żadnych tagów.
Dodajmy więc nowy tag ja tu jeszcze raz.
Wyświetlę sobie git log.
Oneline i git tag mogę wykonać na kilka sposobów mogę nasz git.
Tag.
I podaje jakąś nazwę np. testowa etykieta a następnie tutaj podaje identyfikator commita.
Może być to commit.
Może być to branch.
Jeśli tutaj zamiast tego identyfikatora nie podam żadnego identyfikatora.
Ktoś może pomyślać że automatycznie on tutaj uznaje że jest to head czyli punkt w którym jestem w tym
momencie czyli ten commit na którym się znajduje dodamy do strony.
Ten komitet będzie przypisany do etykiety testowa etykieta a dokładniej rzecz mówiąc to etykieta będzie
wskazywała na ten commit więc spróbujmy zrobić to w ten sposób tutaj usunę i dodajemy nowy tag o nazwie
testowa etykieta który będzie wskazywał na punkt w którym jesteśmy i w tym momencie polecenie git tag.
Jak widzisz wyświetla mi tutaj tag testowa etykieta.
Mogę także stosować to faktycznie z jakimś identyfikatory np. zrobimy jeszcze jeden git.
Tag i użyjemy identyfikatora tutaj jako początek
i tutaj jeszcze umieszczę ten identyfikator.
I w tym momencie git wyświetla mi dwa tagi i każdy z nich wskazuje na inny commit.
I jest to bardzo przydatne bo jeśli potrzebuję któregoś z tych commitów do dowolnego polecenia nie muszę
już wyszukiwać jego identyfikatora jego hasha mogę po prostu podać nazwę etykiety.
W każdym miejscu gdzie oczekiwany jest hash commita i każde polecenie zadziała w taki sam sposób jakbym właśnie podał
konkretny hash.
A jest to dużo wygodniejsze bo nie muszę tych hashy pamiętać.
Czyli np. jeśli ja zrobię sobie tutaj wyświetę te commity i powiedzmy że zrobię git show jak robiliśmy w poprzednich lekcjach
i nie muszę znać całego identyfikatora nie muszę go szukać wystarczy znam jego etykietę.
Czyli np. testowa etykieta.
Jak widzisz tutaj gdzie poprzednio podawałem identyfikator.
Teraz mogę po prostu podać etykietę.
Czyli jest to dużo wygodniejsze polecenie działa tak samo.
Jakbym tam podał właśnie hash i podobnie będzie tutaj z drugim jeśli zrobimy git show i nie testowa etykieta
tylko początek
to wyświetli mi commit
B2 C2 4 i jest to dokładnie commit B2 C2 4 i polecam Tobie spróbować jak te etykiety zachowują się z różnymi
poleceniami z poleceniami reset z poleceniami checkout zobaczysz że dzięki tym etykietom będziesz mógł bardzo
łatwo odwoływać się do starszych commitów i tym razem nie będziesz musiał szukać ich identyfikatorów
więc wszystkie ważne momenty w Twojej aplikacji np. gdy wydajesz nową wersję albo gdy rozpoczynasz jakieś
eksperymentalne zmiany które mogą się nie udać i może chciałbyś się wycofać albo na przykład zrobiłeś jakąś
zmianę do której może będziesz chciał jeszcze wrócić kiedyś wszystkie takie momenty są prawdopodobnie
dobrym momentem właśnie by wykorzystać git log i taki punkt który ma etykietkę po to żeby móc łatwo później się
do niego dostać żeby móc łatwo odnaleźć taki kąt i teraz pokaże Ci jeszcze jak przeglądać logi bo w
momencie gdybyś chciał troszeczkę więcej robi się ich dużo.
Zobaczmy sobie.
Git log git tag i mamy tylko dwa tutaj może to naprawdę jest bardzo dużo.
Mamy jednak opcję taką jak l i normalnie opcję l czyli list po prostu wyświetla wszystkie.
Jeśli jednak tutaj po parametrze list podam wzorzec to mogę odfiltrować tą listę i tylko wyświetlić część
tagów które mają w nazwie jakieś np. litery powiedzmy mamy test i zrobię to w ten sposób to nic nie znajdzie
dlatego że to tutaj jest wzorzec.
Czyli ja muszę zrobić test.
Gwiazdka oznacza to że znajdź wszystkie tagi które zaczynają się od słowa test i zrobię tutaj dwie gwiazdki to znajdź
wszystkie które zawierają w środku słowo test.
I tutaj mamy jeszcze kilka innych możliwości np. początek tutaj
jak widzisz możesz dopasować także brakujące litery czyli wszystkie które zaczynają się
które mają na początku te litery kończą się na takie litery.
Gdzieś musiałem użyć aż dwóch znaków dlatego że polski znak tutaj zajmuje dwa razy więcej miejsca.
Przeważnie wystarczy gwiazdka gwiazdka pozwoli bardzo szybko.
Ofiltrować nadmiar tagów tak żebym miał tylko w wynikach.
To czego potrzebujesz.
Z listą tagów możemy też pracować jakby w odwrotną stronę czyli mając hash danego commita lub inny identyfikator
możemy zobaczyć które commity na niego wskazują czyli poleceniem git tag i powiedzmy contains head.
Mogę sprawdzić który z tych tagów i która historia czyli rodzice tego commita który jest tagowany i jego
rodzice itd itd.
Czyli w której historii znajduje się dany commit czyli ten commit na którym jesteśmy znajduje się
tylko tutaj w testowej etykiecie on się znajduje na początku dlatego że pamiętasz początek wyświetlę git log jak widzisz.
Początek jest tu a my jesteśmy w tym miejscu czyli w tagu początek jeszcze ten commit nasz nie wystąpił.
Natomiast stąd etykieta na wszystkie trzy tagi możesz też dokładnie znaleźć te tagi które wskazują na
dany commit.
W tym wypadku będzie to git log git tag points at i mogę podać tutaj konkretny commit np. mogę sprawdzić
ten mam testowa etykieta a mogę podać ten ostatni
mam początek jeśli podam środkowy to nie mam żadnych tagów chyba że użyję tutaj contains.
I w tym przypadku środkowy będzie zawarty w testowy dlatego że testowy zawiera całą historię a tylko
ten jeden czyli jak widzisz możesz w dwie strony posługiwać się wyszukiwaniem tych tagów czyli etykiety pamiętaj
pozwolą ci bardzo łatwo wrócić przeskoczyć podejrzeć wszędzie użyć tam jakiegoś commita nie musisz pamiętać
za każdym razem wyszukiwać jego cache'a jeśli tutaj utworzyliśmy tych tagów trochę jeszcze warto zrobić porządek i usunąć
czyli spróbujmy jeszcze raz git tag.
Mam tutaj początek i testowa etykieta i poleceniem.
Minus d mogę usunąć powiedzmy.
Początek mam tutaj deleted tag początek i bardzo fajna rzecz bo tutaj pokazuje nam z powrotem hash tego taga.
Więc gdybyś przez przypadek usunął jakiś tag to nic się nie stało.
Mogę zrobić tutaj po prostu jeszcze w ten sposób wkleić z powrotem jako identyfikator i nasza lista
z powrotem wygląda tak samo.
Czyli poleceniem minus d możemy pousuwać nasze tagi jeszcze raz usunę początek git tag delete testową etykietę też usunę.
i mamy tutaj pusto.
I to były tak zwane uproszczone tagi czyli jak widziałeś tylko etykieta.
Na przykład początek wskazujące na jakiś commit czyli na jego hash oprócz uproszczonych tagów mamy także
tagi anotowane czyli jeśli zrobię jeszcze raz git tag.
I powiedzmy na tym commicie na którym teraz jesteśmy zróbmy pierwsza
wersja to tutaj mogę dodać opcję a czyli adnotacja i to tak jak przy tworzeniu commita zapyta mnie o
message czyli o informacje które będą go opisywały czy np. pierwsza
z naszej strony ok escape w i q czyli write i quit.
I teraz jak zrobię git.
Tag mamy pierwszą wersję ale jeśli podejrzę tego taga
to zobacz mam tutaj dwie informacje mam commit na który wskazuje ten tag ale oprócz tego mam adnotację
czyli informację kto utworzył taga kiedy tag został utworzony oraz nasz message czyli wiadomość jaką w
tym tagu umieściłem.
Jeśli chcesz dokładnie opisać co dany tak robi.
Czego dotyczy.
Dlaczego jest ważny.
Chcesz tak zachować informacje od kiedy ten tag został dodany.
Mimo to jak widzisz różni się od daty pewnego commita to właśnie możesz uczyć tej opcji z adnotacją możesz
przecież to prościej usunę.
Czyli git.
Tag usuną go i utworzę go jeszcze raz.
Tylko zamiast opcji a mogę podać opcję n i podobnie jak przy tworzeniu nowego commita to automatycznie
to co podam tutaj w cudzysłowiu to będzie dodana automatycznie jako message.
Nie będzie otwierany edytor nie będziemy go tam zapisywać tylko tu od razu mogę wpisać pierwsza
strona i podobnie git show.
Pierwsza wersja i mamy ten sam efekt tylko nie musiałem otwierać edytora i zobacz to jest bardzo przydatne
np. kiedy tutaj mam informację kiedy zmiany były zapisane a tu tag może przechować faktycznie informacje np. kiedy
dana wersja strony została opublikowana.
I takich tagów możesz mieć kilka nawet jeśli wskazują dokładnie ten sam commit to w ten sposób
mógł byś przechowywać np. informacje o jakich datach kto o której godzinie opublikował np. stronę w którym
miejscu lub inne tego typu sytuacje i inne tego typu przypadki.
I teraz jeśli użyje git tag wyświetlę go w ten sposób.
Mamy tu tak samo jak poprzednią tylko pierwszą wersję jeśli podamy opcję n np. samo n albo z ilością ile
chce tag wyświetlić powiedzmy tylko samo n to jak widzisz anotowane tagi będą wyświetlane od razu z
opisem w ten sposób żebyśmy tych tagów bardzo dużo można bardzo łatwo wyłapać.
Dokładnie czego dotyczy.
Co tu się stało i nie trzeba wchodzić w każdy z tych tagów po kolei.
Tak więc wiesz już jak korzystać z polecenia git tag wiesz jak tworzyć nowe tagi nowe etykiety które wskazywały
na aktualny commit lub jakiś wcześniejszy inny commit.
Wiesz jak je usuwać.
Wiesz jak je przeglądać oraz też wiesz jak tworzyć anotowane tagi które dzięki message można dużo łatwiej
odnaleźć wśród wielu wielu tagów.
Na koniec tej lekcji jeszcze chciałbym żebyś zapamiętał jedną ważną rzecz mianowicie czym różni się
tag od gałęzi.
Jeśli wykonam polecenie git show ref to wyświetli mi to polecenie wszystkie referencje czyli wszystkie
pliki które wskazują na jakiś commit zwróć uwagę że mam tutaj dwa pliki mamy plik refs heads master i refs tags.
Pierwsza wersja jak widzisz to dokładnie to samo.
To są pliki które wskazują na jakiś commit ale z perspektywy naszej jako użytkownika gita jest to bardzo duża
różnica.
Dlatego że ten tag.
Generalnie wszystkie tagi one będą zawsze wskazywały na konkretny commit.
Natomiast referencje typu heads i referencje typu branch czyli gałęzie one będą przesuwały się razem
z commitami czy będziemy budować nowe commity to te referencje będą mogły przesuwać się wraz z nowymi commitami
i śledzić twoje zmiany w historii dzięki czemu nie będziesz musiał pamiętać żeby za każdym razem dodawać etykiety.
One będą śledziły bieżące twoje postępy więc nawet jeśli przełączysz się na inną historię bardzo łatwo
z powrotem wrócisz do tego commita do ostatniego commita na którym skończyłeś pracę na gałęzi.
Natomiast tagi one będą zawsze wskazywały na ten punkt po prostu w czasie tak żeby tagi przypisywać
do rzeczy których chcesz historycznie zapamiętać.
Natomiast gałęzie czyli branche będą pozwalały śledzić kilka różnych wersji twojego projektu i teraz żeby pokazać
też te różnice ja stworzę sobie nowy commit czyli stworzy plik
dodam plik
testowy commit stworzyłem nowy commit i jeszcze raz wyświetlę referencje i zwróć uwagę.
Co się stało nasz tag mimo że był przypięty na najnowszym commicie.
To on już na tym commicie pozostał natomiast master przesunął się i jeśli zrobisz git show head.
To jak widzisz ten commit na którym teraz jesteśmy.
Będąc na gałęzi master on właśnie przesunął tą gałąź do przodu a tak został w tyle.
Jak widzisz tagi są bardzo przydatne do pamiętania punktów historii natomiast do śledzenia bieżącej pracy
dużo bardziej praktyczne są właśnie gałęzie a o gałęziach będziemy już rozmawiać w kolejnych lekcjach.
Do zobaczenia.