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 dowiedziałeś się jak wykorzystać polecenie git tag aby tworzyć własne etykiety i przypisywać
je do commitów w twojej historii dzięki czemu nie musisz już pamiętać dokładnych hashy nie musisz ich
odszukiwać tylko możesz wszędzie tam gdzie dotychczas korzystaliśmy z długich hashy możesz po prostu użyć nazwy
twojej nowej etykiety i działa to dokładnie w ten sam sposób ale jest dużo dużo wygodniejsze w tej lekcji
pójdziemy o krok dalej i pokażę ci jak dodawać nowe typy referencji.
Nie będą to tym razem etykiety ale będą to gałęzie do pracy z gałęziami.
Będziemy wykorzystywać polecenie git branch i to polecenie git branch wykona samo bez dodatkowych argumentów.
Po prostu wyświetli mi ono listę wszystkich gałęzi wszystkich branchy.
I w tym momencie jest to tylko master master czyli główna podstawowa gałąź na której dotychczas cały
czas pracowaliśmy.
Polecam jednak takie polecenie git branch.
Jeśli chcemy wyświetlić sobie listę takich branchy wykonać tutaj z poleceniem v czyli poleceniem verbose i takie
polecenie verbose jak widzisz wyświetla nie tylko nazwę tutaj gwiazdka wskazuje na aktywny ten nad którym
jesteśmy właśnie ustawieni ale także mamy informację o commicie na który wskazuje ta gałąź wskazuje
ten branch no i message informacja opis tego commitu polecenie git branch z opcją list działa dokładnie
jak polecenie poprzednie polecenie.
Wcześniejsze tutaj git branch bez żadnych parametrów.
Oczywiście mogę także v dodać tutaj.
Jednak takie polecenie pozwala także Tobie wyszukać konkretne branche po nazwie czyli np. jeśli mamy
ich bardzo dużo mogę wpisać po prostu tag mogę wpisać mas.
I tutaj nie znajdziemy niczego chyba że tę gwiazdkę czyli jak widzisz tutaj mogę tak jak w poprzednich lekcjach.
W niektórych miejscach wykorzystywać wzorce czyli niepełne nazwy lub nazwy w których część powiedzmy
Master część liter jest zastąpiona gwiazdką.
I takie coś się bardzo przydaje szczególnie jeśli tych etykiet lub gałęzi jest bardzo bardzo dużo.
Pozwala to bardzo szybko odfiltrować.
I oczywiście mogę także użyć tego z opcją v czyli mogę też zobaczyć poszczególne wiadomości tutaj jeszcze
wyczyszczę te wszystkie polecenia i polecenie git branch nie pozwala Tobie wyszukiwać tutaj od razu w ten sposób
dlatego że podanie nazwy w tym miejscu nazwa utworzy nam nowe branch o takiej właśnie nazwie.
Jako drugi argument mogę podać jakiś commit od którego chciałbym utworzyć na przykład tutaj head.
I jeśli nie podam tego drugiego argumentu to też jak w wielu przypadkach poprzednich pamiętasz nie podanie
źródłowego żadnego commita automatycznie wybierze za nas head czyli w tym momencie zróbmy sobie bardziej
praktyczny przykład zrobimy git log
i mam tutaj naszą taką prostą stronę internetową.
Tu są jakieś przykładowe pliki źródłowe.
Mam też tą stronę uruchomioną.
Wygląda na tej jak widzisz bardzo ambitnie mamy jakiś obrazek i jakąś treść i powiedzmy że chciałbym
zmodyfikować tą grafikę.
Chciałbym tutaj dodać coś jeszcze jakieś style jakiś jeszcze nagłówek ale właśnie powiedzmy że przychodzi
w pracy do ciebie ktoś klient przełożony itd prosi o jakąś zmianę jakby równolegle do tego co teraz
robisz.
Czyli wyobraź sobie że chciałbym tutaj jeszcze w tym masterze dodawać kolejne operacje ale równolegle chciałbym też
pracować już nad inną wersją np. chciałbym mieć logo tak jak mam w tym momencie oraz chciałbym spróbować stworzyć
inną odrębną wersję ale w taki sposób by nie uszkodzić nie zmienić tych oryginalnych plików czyli co
chcemy zrobić chcemy mieć dwie równoległe wersje projektu w każdej będziemy mogli wprowadzić różne eksperymenty
zmieniać coś a następnie wybrać np. jedną czy drugą albo spróbować.
Zmiany wprowadzone w jednej w drugiej połączyć to z powrotem do jednej wspólnej wersji czyli w tym momencie
zobaczymy git status jestem na gałęzi master i poleceniem git branch powiedzmy tutaj nazwijmy to nowe
logo w ten sposób mogę dodać head.
I w tym momencie nowa gałąź o nazwie nowe logo byłaby utworzona na podstawie ostatniego commita na którym
jesteśmy.
Czyli ten tutaj na który teraz wskazuje wskaźnik head.
Jeśli jednak pominę ten wskaźnik lub podam konkretny hash jeśli pomininę ten wskaźnik całkowicie no to domyślnie
on wybierze po prostu head i teraz git branch.
Nowe logo.
Sprawdźmy polecenie git branch list jak widzisz mam tutaj dwa branche branch master i branch nowe logo aby przełączyć
jak widzisz gwiazdka teraz wskazuje na pierwszy przełączyć na drugi branch wykonuje polecenie git checkout
i teraz.
Jeśli pamiętasz git checkout pozwalało to polecenie pozwalało wybierać starsze wersje z historii i umieszczać je
w naszym katalogu roboczym.
Dlaczego.
Dlaczego to wykorzystuje.
To polecenie jakby do czegoś innego do zmieniania branchy.
Jeśli zastanowisz się nad tym jak działa git to zobacz git checkout powiedzmy nowe logo to polecenie
zobacz że chce wydobyć z jakiegoś innego brancha z jakiejś gałęzi chcę wydobyć wszystkie pliki właśnie
w tej wersji nowe logo i umieścić w moim katalogu.
I teraz właściwie zamiast za umieszczać wyciągać wszystkie pliki z historii dużo prościej jest po prostu
przeskoczyć na to miejsce w historii z którego chcemy pliki nieprawdaż.
I właśnie dlatego git checkout ma podwójne działanie.
Jeśli wybieram pojedyncze pliki one są umieszczone w mojej gałęzi natomiast ja chcę wszystkie pliki z jakiejś
gałęzi no to zamiast wybierać właśnie po kolei wszystkie pliki my przełączamy się na inną gałąź czyli tutaj git checkout
ma nowe logo sprawdzę jeszcze raz git branch list.
Jak widzisz tym razem gwiazdka i kolor zielony znajduje się przy nowym logo jeśli wyświetlę dodatkowo
opcję v to jak widzisz obie te gałęzie wskazują na ten sam commit dlatego że przy tworzeniu tego brancha
właśnie dlatego że domyślnie branch tworzony jest na podstawie head czyli aktualnego konta jako że master
znajdował się master wskazywał na head czyli teraz obie te gałęzie wskazują na to samo miejsce w historii.
Czym jednak to różni się od etykiet.
Mianowicie jak pamiętasz etykieta zawsze wskazywała na ten sam commit.
Nawet gdy powstawały nowe zmiany ale jak pamiętasz gdy dodawaliśmy nowe rzeczy do mastera on zmieniał kąt na który
wskazuje i ta sama zasada tyczy się tutaj nowych gałęzi czyli jeśli tutaj dodam commit to ta gałąź będzie śledziła
wszystkie następne commity mimo że ten master zostanie w tyle jakby później przełączyć się na mastera
dodać nowe zmiany a wszystkie zmiany wprowadzone tutaj jakby na osobnej gałęzi w osobnej wersji mojego
projektu one będą tam bezpiecznie czekać.
Nim jednak przejdziemy do pracy z tym branchem powiedzmy że chcemy zmienić jego nazwę chcemy podać jeszcze te
wszystkie polecenia czyli git branch.
I tu mam jeszcze opcję m czyli move i mogę np. moje nowe logo zamienić na nowy nagłówek git i jeszcze
wyczyszczę i teraz tutaj nic się nie zmieniło zmieniła się jakby tylko nazwa on dalej wskazuje ten sam commit
dalej jest na tym samym punkcie w historii co nasz Master ale tym poleceniem właśnie m.
Czyli move tak samo jak w systemie unix po prostu pliki przenosimy opcją move tutaj robię m.
Mogę zmienić nazwę brancha i czasem się to przydaje.
Jeszcze jedną rzecz mianowicie tutaj przełączyć się z powrotem git checkout master przełączam się na mastera
i jeśli chciałbyś usunąć branche to git
branch minus d jak delete.
Jeśli przypadkowo usunąłeś nie ten branch co trzeba zawsze tutaj pokazuje ci commit więc zawsze mogę
sobie stworzyć teraz jeszcze raz.
Czyli git branch nazwa.
I tutaj ten commit będzie oznaczał właśnie commit na który ma wskazywać ta nasza nowa referencja ta nasza
nowa gałąź chcę ci pokazać jeszcze jedną ważną rzecz.
Jeśli tworzysz szybko branche to zobaczysz że musiałam wykonać dwa polecenia.
Musiałam stworzyć nowy branch płaceniem git branch nazwa brancha oraz następnie musiałem zrobić git checkout
i ponownie podać tą samą nazwę brancha można to zrobić dużo szybciej.
Mam teraz jeden branch jesteśmy na masterze więc poleceniem git checkout z parametrem b czyli branch.
Mogę od razu w jednym poleceniu utworzyć nowy branch i od razu się na niego przyłączyć.
Czyli tym razem będzie to nowy nagłówek.
Jak widzisz teraz od razu jestem na tym branchu który stworzyłem i możemy wykonać jakąś pracę.
Ja tu wejdę na naszego edytora i wprowadzę przykładowe zmiany.
Nie jest istotne to co ty u siebie zrobisz.
Ważne żeby mieć coś innego niż będziemy robili w tym głównym głównej gałęzi dodam sobie jakichś klas.
Zobaczmy tu pojawią się jakieś przykładowe style dodam sobie klas
jakiś nagłówek CSS to są mniej istotne rzeczy.
Ja wkleję gotowe jakieś CSS'y zobaczmy czy coś się zmieniło.
Strona wygląda tak samo odświeżę to jak widzisz zmieniło się.
Tu jeszcze mogę dodać
zobaczmy praktyczne zmieńmy jeszcze troszeczkę tutaj jeszcze wpisze może troszkę inny tytuł.
Może zrobię w ten sposób
praktyczne porady.
Ok powiedzmy że jest OK.
Zmieniłem troszkę style zmieniłem nagłówek i nie wiadomo czy ta zmiana będzie zaakceptowana.
Nie wiemy jeszcze czy ona pozostanie.
Dlatego właśnie wprowadziłem tę eksperymentalną taką zmianę nagłówka.
Na osobnej gałęzi.
Po to żeby móc w każdej chwili się wycofać lub po prostu powrócić do tej pracy np. za jakiś czas wrócimy
do gita.
Oczywiście git status jak już wiesz git add mogę dodać oba pliki git commit.
I tutaj nazwijmy commit powiedzmy zmieniony nagłówek to będzie praktyczne porady.
Ok i teraz zwróć uwagę że commit tworzony jest zawsze na head czyli na aktualnym historii na który jesteśmy
na aktualnej gałęzi.
W sensie commit jest tworzony z rodzicem czy rodzicem.
Tego commita jest commit na którym byliśmy a następnie gałąź na której jesteśmy jest przesuwana do przodu o jeden
czyli sprawdźmy.
Zrobimy sobie może nie tak zrobimy.
Git log.
Jak widzisz mam dodatkowy commit ale zwróć uwagę gdzie my jesteśmy.
Jesteśmy tutaj na branchu.
Nowy nagłówek.
Jeśli teraz wyświetlę brunch jeszcze raz to zwrócił uwagę że one się rozsynchronizowały.
Master pozostał tam gdzie go zostawiliśmy na commicie 8f dodano style.
Natomiast nowy nagłówek jest o jeden commit do przodu przed masterem.
Oznacza to że ja mogę równolegle tworzyć dwie różne historie niezależne od siebie i właśnie one są niezależne
a one są zupełnie bezpieczne czyli mogę tutaj eksperymentować tworzyć zmieniać historię.
Wszystko co robiliśmy dotychczas na masterze w poprzednich sekcjach w poprzednich lekcjach.
Ja mogę dowolnie tworzyć niszczyć zmieniać i to zupełnie nie wpływa na oryginalną gałąź master i to
jest jakby najważniejsza z cech gita że każdy z deweloperów może wybrać dowolny punkt w historii np.
bieżący aktualny master może na podstawie tego punktu stworzyć własną odrębną gałąź i tam eksperymentować
tworzyć dowolnie zmieniać rozgałęziać bez ryzyka uszkodzenia zmiany tych oryginalnych plików i później
będziemy mogli albo te zmiany z powrotem połączyć z masterem albo po prostu je usunąć zniszczyć i nie
ma z tym żadnego problemu.
To jest bardzo potężne narzędzie i to jest bardzo dużą różnicą w porównaniu z nvm'em czy innymi systemami jest
to że branche są bardzo lekkie i teraz co to oznacza.
Jeśli ja chcę przełączyć się między tymi dwoma branchami to jest to bardzo proste.
Oczywiście git checkout i pamiętasz jak tworzyłem nowego brancha to stworzenie nowego brancha było błyskawiczne
praktycznie stało się od razu i tak samo przełączanie się np. na mastera dzieje się także błyskawicznie
dlatego że jak pamiętasz.
Tutaj zarówno poszczególne gałęzie branche jak i sam wskaźnik head to są tylko pliki zawierające hash commita.
Tak więc takie przełączanie się między branchami oznacza przyłączenie tego pliku.
Przyłączenie heada oraz przeniesienie tylko plików które różnią się między tymi branchami tymi gałęziami
w naszym katalogu roboczym więc jeśli przesuwasz przestawiasz się między branchami które zostały zmodyfikowane
niedawno nie różnią się za bardzo od siebie no to taka zmiana jest błyskawiczna.
Jeśli chciałbyś przełączyć na jakiś bardzo stary lub zupełnie inny branch od twojego.
Taka zmiana może zająć chwilkę.
Niemniej jednak jest to nadal bardzo bardzo szybko.
Tutaj przełączyliśmy się na branch master.
I co to oznacza.
To oznacza że jeśli zajrzę do moich plików to moje zmiany zostały jakby cofnięte.
Tutaj nie ma moich styli i jak odświeżę naszą stronę.
No to nie ma naszego eksperymentu eksperymentalnego nagłówka.
Wszystko jest w tym miejscu w którym były i oczywiście mogę jeszcze w drugą stronę w każdej chwili git.
Checkout nowy nagłówek tak że błyskawicznie przełączam się i od razu widzę zmiany.
Jest to bardzo wygodny tryb pracy bo jak widzisz możesz równolegle bardzo szybko pracować na kilku wersjach
przełączać się między nimi i jednocześnie masz gwarancję że żadna z tych ścieżek żadna z tych historii
nie wpływa na pozostałe czyli nie utracisz zmian nie pomieszasz tu nic nie poplątasz i w każdej z tych historii
w każdej gałęzi możesz stosować wszystkie triki wszystkie sposoby mechanizmy polecenia których nauczyłeś
się podczas poprzednich lekcji w pracy lokalnej.
Czyli możesz faktycznie modyfikować pliki możesz modyfikować historię możesz cofać zmiany przywracać
zmiany wszystko co robiliśmy.
Możesz spokojnie robić to w ramach jednej gałęzi.
Jest to bezpieczne.
Nie wpłynie to na inne zmiany w kolejnych lekcjach dowiesz się jeszcze więcej o pracy z gałęziami jak
np. przywracać zmiany jak łączyć jak wybierać pojedyncze zmiany.
No właśnie ale o to już wszystkim w kolejnych lekcjach dziękuję i do zobaczenia.