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!
Z poprzednich lekcji wiesz już jak wyodrębnić twoje pliki.
Twoją pracę do odrębnej gałęzi.
W jaki sposób prowadzić równoległą pracę na kilku różnych wersjach plików twojego projektu a następnie
gdy pewna część prac już jest skończona.
W jaki sposób.
Znowu przy użyciu polecenia git merge jak połączyć z powrotem te zmiany do głównej gałęzi master.
Tym razem jednak nie będziemy korzystali z polecenia git.
Merge ale z polecenia git.
Rebase z tego pelecenia korzystaliśmy już wcześniej.
Służyło ono do modyfikacji istniejącej historii i jak już wiesz wiele poleceń w gicie możesz zastosować
w różnych sytuacjach na różne sposoby.
I tak samo tutaj polecenie git rebase jest jak zobaczysz za chwilę pozwoli nam przenieść zmiany z jednej
gałęzi na drugą ale w inny sposób niż merge.
Zacznijmy więc od stworzenia jakichś zmian.
Jestem na gałęzi master.
Zobaczcie jak nasza historia mieliśmy gałąź.
Nowy nagłówek tą gałąź zintegrowaliśmy w tym miejscu jak widzisz rozgałęzia nam się i z powrotem powracamy do głównego.
Mieliśmy także gałąź spis treści która tutaj oddzieliła tu były jakieś zmiany i jedne zmiany były połączone właśnie
w naszym poprzednim commicie typu merge który integrował zmiany z mastera oraz spis treści.
I teraz powiedzmy że chciałbym znowu pracować na spisie treści ale chciałbym właśnie te zmiany robić
w osobnej gałęzi czyli tutaj tak żeby dopiero jeśli będą gotowe z powrotem dołączyć do mastera.
Jeśli przyjęta do spisu treści gdy damy nowe commity to będzie problem bo znowu jakby rozejdzie się tutaj
z naszym masterem będą to dwie osobne historie.
Zwróć jednak uwagę że master zawiera już teraz spis treści a dodatkowo bo on jeśli z bezpośrednio jego rodzicem
jest już do przodu przed nim a spis treści jest w historii tego mastera ponieważ jak pamiętasz z poprzedniej lekcji jeśli
mamy taką właśnie sytuację gdzie jedna gałąź wyprzedza inną po prostu o parę commitów a ta druga gałąź
jest de facto jej częścią jest w jej historii.
To znaczy że ja mogę jeśli chcę połączyć te zmiany żeby one były aktualne to mogę po prostu przesunąć wskazówkę
spis treści o jeden do przodu i one będą wyrównane czyli będę mógł zrobić fast forward merge czyli zamiast
dołączać zmiany z mastera teraz z powrotem do spisu treści tak żeby one były zaktualizowane żeby były zsynchronizowane nie muszę tutaj
robić takich skomplikowanych rzeczy lecz polecenie git merge po prostu przesunie mi spis treści tam gdzie jest master i
w ten sposób zwróć uwagę że jeśli będę dodawał nowe zmiany w spisie treści to te zmiany będą miały wspólnego
rodzica razem z masterem.
To znaczy że później zmerge'owanie tych zmian znowu do mastera także nie będzie problemem dlatego że miały wspólną
historię wspólny punkt zaczepienia lub inaczej jak to w tej lekcji nazwiemy będzie to wspólna baza wspólny
punkt odniesienia dla tego merge'a.
Mam nadzieję że to będzie jasne za chwilkę przełącze się na spis treści spis treści tutaj zobaczymy
jeszcze raz.
Jak widzisz wskazówka head przyłączyła się z mastera na spis treści i teraz co będę chciał zrobić
to chciałbym aby spis treści teraz jak on już jest zmerge'owany czyli włączone w stosunku do mastera.
To chciałbym kolejne zmiany robić właśnie od tych najnowszych zmian które mam na masterze tak żeby kolejne
zmiany które wprowadzam żeby już miały zintegrowane wszystkie poprzednie zmiany ale nie chcę tego robić
na masterze chcę nowe zmiany wprowadzać tutaj żebym w razie czego mógł je wycofać zrezygnować poprawić i dopiero
gdy wszystko będzie gotowe dopiero wtedy dołączysz je do mastera.
Więc na razie co robimy.
Na razie zsynchronizujemy.
Oba te gałęzie to znaczy żeby pracę którą tutaj będę wykonywał żeby ona dalej mogła się rozwijać
co mamy w głównej gałęzi ale nie modyfikując jej czyli po prostu robię git merge.
I tu zwróć uwagę nie będzie to pełny prawdziwy merge bo ja po prostu mogę przesunąć się o jeden
czyli spis treści przesunie mnie tam gdzie jest master i head.
Będzie też w tym samym miejscu.
Czyli spróbujmy git merge master zwrócisz uwagę że robimy odwrotną rzecz niż poprzednio jeśli prowadziliśmy
zmiany na pobocznej gałęzi.
I one były gotowe.
Aktualizowaliśmy główną gałąź.
O te zmiany czyli zintegrowaliśmy zaakceptowaliśmy te zmiany do głównej gałęzi.
Gdy teraz jednak przyłączyłem się na ten spis treści to on jest nieaktualny pokażę tu jeszcze edytor jak pamiętasz tu mieliśmy
chyba sześć różnych pozycji.
Teraz gdy wróciłem do spisu treści mamy z powrotem tylko trzy więc jeśli teraz bym dodawał kolejne pozycje bo to jak widzisz
edytowałbym stare pliki starą wersję więc nim dodamy tutaj nowe zmiany do tych plików.
Co musimy zrobić.
Musimy zaktualizować naszą bazę czyli musimy zaktualizować commit.
Najnowsze jakie tu jest do tego samego który jest w masterze i dopiero wtedy będzie mógł dodawać kolejne zmiany.
Gdy skończymy prace i będziemy chcieli z powrotem połączyć te zmiany do mastera to pomyśl już o tym że
GIT nie widział problemu dlatego że oba gałęzie oba branche wywodzą się z tego samego punktu punktu
do którego zaraz tutaj doprowadzimy i dopiero zmiany wprowadzone na jednej gałęzi będziemy po prostu elegancko po
prostu przestawiać przenieść na drugą gałąź czyli teraz jeszcze pierwszą rzeczą którą chcemy zrobić to chcemy aby to co w tej
naszej gałęzi spis treści co jest nieaktualne jak widzisz w edytorze chce poprzez zaktualizować do najnowszej
wersji. Polecenie git
merge master który tutaj sobie wykonam on nam po prostu no właśnie przesunie nas w to samo miejsce gdzie jest master.
Mam tutaj update'ing mamy fast forward czyli nie trzeba tworzyć nowego commita wystarczyło przesunąć się do przodu
jak teraz spojrzymy na nasze drzewko no to zwróć uwagę co się stało tutaj był nasz stary spis treści jeszcze bez tych
najnowszych zmian tu był master który miał wszystkie najnowsze zmiany włącznie z naszym spisem treści
więc co wystarczyło zrobić skoro master już zawierał spis treści.
No to ja mogłem zaktualizować spis treści po prostu przestawiając go tam sam.
W to samo miejsce gdzie master.
I teraz jak widzisz head czyli miejsce w którym jesteśmy teraz wskazuje zarówno na commit z mastera jak
i commit spis treści.
I w tym momencie gdy spojrze do edytora jak widzisz mamy wszystkie nasze najnowsze zmiany.
Mam tutaj sześć pozycji w naszym w spisie treści i teraz zobacz jeśli tutaj dodamy jakiejkolwiek zmiany
to pracujemy na najnowszej wersji czyli jeśli potem skończymy i będziemy musieli zjechać do mastera
to nasze zmiany z masterem nie będzie problemu nie będzie konfliktu dlatego zobacz że po prostu dodajemy zmiany
jakby na masterze.
Tak ale będąc w osobnej gałęzi więc jeśli nie będziemy chcieli dodać będą w spisie treści jeśli będziemy
chcieli połączyć z masterem to też nie będzie problemu dlatego że zmiany w jednej drugiej gałęzi będą wychodziły
z tego samego punktu skoro więc mamy wszystkie najnowsze zmiany.
No to możemy śmiało dodać nowe rzeczy do naszego spisu treści będziemy mogli je zintegrować do mastera
więc przejdę do edytora.
Powiedzmy że tutaj utworze w pracy równoległej w innym miejscu osobne zmiany
OK.
Jako że to jest jeszcze branch roboczy jest to gałąź która nie będzie od razu włączona do mastera.
Jak na razie wprowadzić jakieś zmiany tymczasowe zamiast podawać pełne nazwy rozdziałów czy powiedzmy
pewne tytuły poszczególnych elementów.
Ja troszeczkę uproszczę sobie sprawę i dodam tylko takie notatki które będziemy później rozwijać.
Czyli powiedzmy wpisze piszę tutaj tylko tag.
Branch.
Checkout
i powiedzmy jeszcze jeden dorzucę stash.
Jak widzisz nie są to pełne nazwy tytułów ale nie szkodzi jak pamiętasz historię możemy edytować czyli dopóki nie dołożę
tego do mastera.
Ja mogę spokojnie zmiany sobie wprowadzać zawsze commity zmienić edytować git status zmiany git add index to już wiemy.
Git commit i tutaj dodamy spis treści praca równoległa
tag i zrobimy
work in progress czyli że jeszcze nie skończyliśmy jest to jakiś commit w trakcie pracy.
OK czyli tu wprowadziłem zmiany zobaczmy naszą historię i teraz jak widzisz spis treści poszedł do przodu
jest on nowszy od mastera master nam pozostał w tyle tutaj możemy sobie dodawać zmiany gdy będziemy gotowi.
Moglibyśmy śmiało edytować historię na przykład będę mógł zrobić git rebase tak wcześnie i np. head minus jeden i mógłbym
tutaj
śmiało edytować ostatni commit zmienić jego tytuł.
Mam tu kilka commitów mógłbym je połączyć mógłbym dowolne zmiany w tej historii tutaj dokonywać.
Pod warunkiem że nie zmienię niczego
że nie zmienię niczego dalej niż master bo zwróć uwagę jeśli w tym spisie treści edytowałbym jakieś commity
starsze niż master to znów ciężko byłoby zmergre'ować połączyć bo te dwie gałęzi spis treści w master nie miałby
wspólnej bazy nie miałby punktu zaczepienia od którego git mógłby łączyć te zmiany wyobraź sobie taki np. zamek błyskawiczny
jeśli obie strony zaczynają się w tym samym miejscu to można je śmiało można go zapiąć.
I odpiąć możesz te zmiany połączyć.
Jeśli jednak taki właśnie zamek błyskawiczny jest nierówny te zmiany jakby gdzieś są przesunięte no
git bardzo ciężko jest połączyć.
Powstają wtedy konflikty taki branch ciężko jest zmerge'ować.
Tu na razie elegancko.
Na razie mogę śmiało dodawać i edytować wszystko w tym spisie treści tak długo jak nie edytuję żadnego
commita starszego niż ten chociaż pokażę ci jeszcze jeden problem mianowicie powiedzmy że spis treści sobie edytowaliśmy
wszystko jest w porządku zostawiliśmy go na razie wrócimy do niego w przyszłości a w międzyczasie
git checkout master.
W międzyczasie powiedzmy że na masterze weźmy inną pracę może być name na gałęzi name na innym branchu.
Może zmerge'owaliśmy coś do mastera może pobraliśmy jakieś zmiany z jakiegoś serwera w kolejnych lekcjach.
Tak czy inaczej wprowadzimy jakieś zmiany do mastera i zobaczymy wtedy powstanie pewien problem.
Jak widzisz nie widać naszych zmian w pracy równoległej dlatego że te czekają na nas w osobnej gałęzi
gałęzi spis treści.
Ja chcę to dodam sobie w innym miejscu dodam np tutaj zmiany
powiedzmy wpiszemy sobie czym jest git git.
Ok intalacja.
Instalacja gita dodajemy co tu jeszcze może być
tu może zróbmy tak konfiguracja
ok czyli załóżmy że w masterze powstały jakieś zmiany które specjalnie robię w innym miejscu żeby akurat nie było
konfliktu przy ich łączeniu czyli teraz już można było śmiało łączyć ten spis treści na dole z tymi zmianami
góry scommitujemy
indeks git commit spis treści podstawy podstawy tudzież wprowadzenie OK.
I teraz tu i tu dodałem commity czyli te dwie gałęzie powiedzmy rozgałęziły się każda poszła w swoją inną
stronę.
Zobaczmy teraz jak wygląda sytuacja.
Dokładnie tak jak poprzednio każda.
Każde rozgałęzienie.
W końcu my robiliśmy merge czyli tu robiliśmy merge który z powrotem.
Nowy nagłówek nam połączył z gałęzią master w którym mieliśmy merge spis treści który połączył nam spis
treści ale następnie zarówno w masterze jak i spisie treści stworzyliśmy commity które różnią się one
mają wspólną bazę czyli oba rozpoczynają się stąd ale każde z nich wprowadza inne zmiany i ten wprowadza
zmiany plików w miejscu podstawy.
Drugi tutaj wprowadza w ostatniej części spisu treści.
Czyli aby każdy idzie w inną stronę i o ile tę gałąź główną naszą master ja mogę dalej śmiało modyfikować
mogę dokładać nowe commity.
Dlatego że i tak do tej właśnie gałęzi będziemy wszystko łączyć tak pojawia nam się pewien problem ze spisem
treści.
Jak pamiętasz przed chwilą ja specjalnie aktualizowałem spis treści do najnowszego mastera żeby później
można było bardzo łatwo go zintegrować można po prostu zrobić fast forward czy prostego merge'a i zintegrować
spis treści do mastera.
Teraz jednak gdy przejdziemy do mastera do spisu treści czyli git checkout spis treści OK.
I teraz tutaj ja będę przed właśnie jestem za masterem ale mam już jakieś zmiany czyli jak widzisz nie mogę zrobić
w fast forward.
Nie mogę sobie łatwo przesunąć.
Jeśli teraz zrobię git merge no to powstanie nowy commit który połączy mi te nasze zmiany z masterem i dopiero
wtedy będziemy mogli połączyć do mastera.
Będziemy mieli taki brzydki dodatkowy commit jeden.
Prawdopodobnie to będzie jeszcze drugi w połączeniu z masterem.
Idealnie byłoby gdyby ten nasz spis treści.
On zawsze był przed masterem czyli zawsze był zsynchronizowany z masterem i dalej moglibyśmy ten commit który ostatnio
zrobiliśmy jakby odłożyć na bok zaaplikować wszystkie nowe zmiany z mastera.
I wtedy ten nasz commit zaaplikować z powrotem w naszej gałęzi spis treści.
Tak jakby właśnie on dopiero został nałożony na najnowszą najświeższą wersje mastera i można
by to robić kilkoma różnymi poleceniami.
Ale jak pamiętasz polecenie git rebase pozwalało nam modyfikować historię.
I ja mógłbym tutaj zdejmować przekładać usuwać commity.
Ale jest jeszcze prostszy na to sposób mianowicie będąc w spisie treści
czyli tutaj spis treści.
Ja mogę te wszystkie zmiany jakie tutaj są nowsze niż poprzedni wspólny punkt odłożyć na bok czyli de
facto cofnąć spis treści do tego commita zaaplikować wszystkie zmiany czyli go przesunąć jak.
Robiliśmy to przed chwilą fast forward przesunąć go tam gdzie jest master.
I wtedy wszystkie zmiany które tu zrobiliśmy z powrotem zaaplikować ale już na najnowszej wersji naszego
kodu.
Czyli teraz tutaj mamy taką sytuację że mamy naszą pracę równoległą nie mamy tych podstaw git.
Więc co byśmy zrobiliśmy chcielibyśmy tą pracę równoległą czyli te wszystkie commity odłożyć na chwilę na
bok czy je wycofać zaaplikować te commity z mastera i wtedy nałożyć z powrotem nasze commity żeby tu była ładna czysta
historia.
I teraz tak żeby to zrobić poleceniem git.
Rebase i tym razem nie.
I tutaj nie i i head dlatego że takie polecenie pracowało na bieżącej gałęzi na bieżącym branchu na którym akurat
jesteśmy my dokładniej chcemy pracować na tym którym jesteśmy ale nie modyfikować tylko go.
Ale chciałbym zrobić zmianę bazy w bieżącej gałęzi na bazę master czyli git rebase master i co takie polecenie
zrobi to polecenie właśnie zdejmie z naszej aktualnej bazy wszystkie commity.
Stąd czyli cofnie nas do wspólnego punktu z masterem czyli tam gdzie master i spis treści się rozgałęziły.
Tam się cofniemy zaktualizujemy wszystkie commity z mastera czyli tak jakbyś przed chwilą git merge master
który dał nam fast forward czyli to nas cofnie tu przesunie nas do mastera z powrotem do góry.
Czyli stąd cofnie tu przesunie wskaźnik do góry.
Tak więc że master head i spis treści będą w jednym miejscu a następnie te wszystkie zmiany które odłożyłem
na bok aby cofnąć się do tego punktu z powrotem zaaplikację na samej górze i dzięki temu nasze wszystkie
zmiany będą najnowsze będą przed masterem i dzięki temu że one będą wychodziły bezpośrednio z mastera
będziemy je mogli w prosty sposób zmerge'ować.
Przy użyciu fast forward czy prostu jeśli będziemy przed masterem połączyć z masterem no to znowu przesunie master
do przodu.
Spróbujmy to zrobić git rebase master i teraz zobacz najpierw cofamy wskaźnik head aby ponownie czyli repley czyli
ponownie wykonać zaaplikować swoją pracę.
I tu jest dopiero applying spis treści.
Praca w Work in Progress czyli on faktycznie cofa wskaźnik head tutaj aplikuje.
Wszystkie zmiany z mastera a następnie przywraca z powrotem nasze commity i tutaj znowu.
Jeśli byłaby akurat zmiana te same linie w masterze.
I tu w spisie treści no to oczywiście mielibyśmy konflikt do rozwiązania ale teraz wyobraź sobie że taki
spis treści był skonstruowany już dawno temu.
W tym czasie pojawiło się bardzo dużo zmian i gdybym chciał zmerge'ować tego nowego nowiusienkiego mastera
do tego starszego spisu treści byłoby to bardzo dziwny merge musiałbym stary w stary kod wprowadzić dużo nowych
zmian i tak zrobiłbym merge w tym przypadku przy rebasie jest o tyle fajna sytuacja że zmieniamy kolejność
rzeczy w czasie.
Prawidłowo powinno wykonać to tak że gdybyśmy nie mieli gita zmiana musiałaby czekać musiałbym najpierw wykonać
zmiany na masterze dopiero wykonać skończyć spis treści gdy skończę zaaplikować go do mastera i dopiero zacząć
kolejną pracę tak żeby poszczególne zmiany działy się jedne po drugich.
W odpowiedniej kolejności natomiast git rebase pozwala nam troszeczkę oszukać pozwala z bieżącego miejsca w masce rozpocząć kilka
równoległych operacji kilka prac kilka różnych gałęzi dodać sobie zmiany tak jakby był tylko jeden
master.
I właściwie jest tylko jeden master a następnie gdy chcemy integrować to robimy właśnie taki trik że
wkładamy tego mastera najnowszego pod nasz branch i aplikujemy nasze zmiany jeszcze raz i daje to taki efekt jakbyśmy
te zmiany nie robili ich dawno dawno temu ale jak byśmy te zmiany wprowadzali właśnie teraz właśnie
na najnowszym masterze czyli ten git rebase pozwalaja nam tutaj troszeczkę oszukać czas i wprowadzać równoległe
zmiany na jakiejś gałęzi na przykład na masterze a potem zasymulować tak jak byśmy robili jedna po drugiej po prostu układając
jedne zmiany po drugich aplikując je w takiej kolejności jakby one się działy gdybyśmy nie pracowali równolegle
gdybyśmy pracowali po kolei i to będzie bardzo ważne dlatego że to nam pozwoli właśnie na pracę zespołową
o której będziemy rozmawiać w kolejnych lekcjach i pozwalają na bardzo łatwe integrację zmian z naszych
lokalnych branchy na naszych komputerach np. do głównego centralnego serwera w taki sposób żeby tę integrację.
Te zmiany będą bardzo łatwe do połączenia.
Natomiast osoby które będą przeglądały historie będą miały jedną czystą historię która będzie wyglądała
tak jak gdyby wszyscy pracowali po kolei a nie równolegle.
Teraz zobaczmy jak wygląda nasze drzewko czyli na początku przesłaliśmy wszystko do mastera a następnie
gdy zaaplikowaliśmy tę zmianę nasz spis treści no to spis treści poszedł o jeden do przodu czyli tu są
nasze zmiany ale zobacz teraz że nasze zmiany wywodzą się bezpośrednio z mastera.
Czyli jesteśmy do przodu.
Spis treści jest uaktualniony mimo że tu i tu były wprowadzone zmiany i teraz ponownie gdy postanowię
przejść do git checkout master
czyli do mastera.
Tutaj zobaczymy jeszcze raz grab to jak widzisz master tutaj jest jednym commitem do tyłu za spis treści.
Czyli jeśli chcemy spis treści zintegrować do mastera to nie muszę znowu tworzyć nowego commita żeby
master był aktualny.
Wystarczy znowu przesunąć wskaźnik head przesunąć wskaźnik master na ten commit i wtedy wszystkie trzy
czyli head master i spis treści będą w tym samym miejscu co oznacza że będą one zsynchronizowane.
Czyli jeśli zrobię teraz git merge to już nie robię rebase bo nie zmieniam bazy po prostu dołączam spis treści
do mastera i git merge twierdzi aha tutaj one jedne wynikają z drugich są w jednej liniowej historii.
Czyli ja mogę śmiało po prostu przesunąć wskaźniki jak widzisz mamy fast forward.
Nie mamy tutaj żadnych konfliktów nie mamy dodatkowego commita widać co się stało.
To po prostu jak widzisz przeniosłem tutaj wszystkie wskazówki do góry i taki work flow jest bardzo wygodny
dlatego że możesz każde zmiany twoje wprowadzić na jakimś osobnym dodatkowym branchu na jakiejś osobnej gałęzi.
Jeśli te zmiany są niekompletne lub chcesz je odrzucić nic nie szkodzi twoja gałąź master jest cały czas czysta.
Możesz w każdej chwili jeśli któryś z gałęzi ma ukończoną gotową pracę możemy dołączyć ale pamiętaj
nim dołączysz nim zmerge'ujesz jakąś gałąź do głównej gałęzi master pamiętaj żeby te zmiany były aktualne
tzn żeby te zmiany zawierały już w sobie wszystkie najnowsze zmiany w master dlatego że nie chciałbyś
po prostu nadpisać mastera jakimiś starymi plikami starymi zmianami.
Chcesz dodać najnowsze zmiany do najnowszych zmian mastera.
Więc co robimy robimy rebase.
Czyli zmieniamy bazę naszego spisu treści czy twojej innej gałęzi tak żeby wszystkie twoje zmiany przesunąć
przed mastera żeby były one nałożone jeszcze raz na najnowszy stan twojego projektu.
I dopiero wtedy jak wszystko się zgadza jak rozwiązaliśmy aktualne konflikty.
Gdybyś chciał połączyć z gałęzią master to nie ma problemu jak widzisz taki merge jest szybki bezproblemowy
i szczególnie gdybyście pracowali w zespole.
Jeśli ty wprowadzasz zmiany w jakichś plikach są to przeważnie twoje pliki ty wiesz czego one dotyczą.
Dużo lepiej jest jeśli to ty rozwiążesz konflikty bo są to twoje pliki.
Ty wiesz jak to powinno działać.
Jakie rozwiązanie jest prawidłowe i jeśli twój commit jest czysty jeśli twój commit bezpośrednio rozszerza
mastera wynika z mastera to wysyłając takie zmiany na serwer.
Bardzo bardzo ułatwiasz pracę swoim kolegom z zespołu dlatego że po prostu integracja jest bardzo prosta
po prostu pobranie zmian wygląda w ten sposób nie trzeba po ich stronie rozwiązywać żadnych konfliktów
wyczyszczę ekran.
Zobaczmy sobie.
Edytor i teraz jak widzisz mamy tutaj zarówno zmiany z tego miejsca jak i zmiany tutaj.
Stąd zostało nam wszystko zintegrowane czyli tak jak byśmy zrobili merge'a ale różnicą jest to że jeśli zrobię git log oneline.
To tutaj tym razem jak widzisz nie ma żadnego commita merge.
Wszystkie commity wyglądają tak jakby były dokonane bezpośrednio na masterze.
Czyli nasza historia jest uproszczona.
Nie mamy tutaj merge merge merge nie mamy tak jak tu sytuację tych tych punktów łączenia nie ma.
Wygląda w ten sposób jakby powstawała na jednej gałęzi dlatego też jest to polecenie rebase polecenie
rebase jak pamiętasz właśnie służyło do modyfikacji historii i polecenie rebase właśnie z kilkoma branchami
pozwala zrobić dokładnie to czyli pozwala nam uzyskać bardzo ładną elegancką historię przy łączeniu dodatkowych
zmian.
Teraz kilka ważnych rzeczy jeśli chodzi o rebase.
Rebase jest bardzo pomocny.
Jest to potężna rzecz które wykonuje za nas wiele operacji.
Pozwala uprościć historię.
Pozwala także na bardzo łatwe merge'owanie później w górę.
I teraz co znaczy w górę.
Jeśli mamy ma branch master to jest nasz główny branch my chcemy do niego wszystkie integrować zmiany jeśli nasz branch
nazywa się spis treści no to jest to mniej ważny jest to branch downstream czyli jest to miejsce
z którego jakby zmiany będą integrowane do mastera i teraz master to jest ten upstream dlatego że tam zawsze jest
najświeższe najważniejsza prawidłowa wersja projektu żeby góra strumienia czyli miejsce skąd chcemy
pobierać zmiany.
Jest to miejsce skąd chcemy rebase'ować.
Miejsce od którego chcemy zaczynać pracę na nowych gałęziach na nowych branch'ach.
I teraz jeśli rebase'a robisz wykonujesz to polecenie na mniej ważnych gałęziach na takich które będziesz
później dołączać do tych głównych gałęzi no to ok bo to pozwala ci później bardzo łatwo integrować.
Niebezpiecznie jest robić rebase jest nie jest zalecane robienie rebase'a w drugą stronę tzn.
Nie chciałbym teraz na przykład wykonać takiego polecenia jak git rebase.
Spis treści dlatego że zwróć uwagę takie coś zmodyfikowało by mi historię tej głównej ważnej gałęzi na
podstawie jakiejś mniej ważnej gałęzi.
I o ile na moim repozytorium lokalnym jeszcze nie byłby to taki problem bo było to samo co zrobienie po
prostu rebase i lub git reset hard po prostu operację zmiany historii.
Jednak zwróć uwagę że jeśli taki master byłby udostępniony na serwerze i inne osoby także korzystały
by z tego mastera jako właśnie góry strumienia jako miejsce z którego pobierają najnowsze najaktualniejsze
zmiany to ja zmieniając taki master czy jeśli ja edytowałbym historię czy torebase i czy git rebase jakaś nazwa
brancha czy jakikolwiek inny ze sposobów modyfikacji historii i taką zmienioną historię wysłałbym np.
na serwer gdzie pracowało więcej osób to osoby pobrałyby taką zmienioną historie to zwróćcie uwagę że
wszystkie gałęzie które dotychczas były przez nie aktualizowane do tego mastera nagle stały by się nieaktualne.
Czyli zrobienie czegoś takiego spowodowałoby duży bałagan w reszcie zespołu dlatego że teraz po takiej
zmianie mastera wszyscy musieliby wszystkie mniej ważne wszystkie ich lokalne zmiany ich branche gałęzie
w których pracują musieliby wszędzie w nich zaktualizować mastera i ta aktualizacja prawdopodobnie nie byłaby
prostą tylko wymagałaby rozwiązywania konfliktów.
Czyli taka operacja z twojej strony sprawiłaby że cały twój zespół zmuszony byłby rozwiązać konflikty.
Więc prawdopodobnie jak się domyślasz nie byliby zadowoleni dlaczego bardzo bardzo nie zalecaną jest
zmienianie edycja historii w głównych ważnych czy najważniejszych współdzielonych przez kilka osób gałęziach
jeśli gałąź jest współdzielona no to praktycznie zmiany powinny płynąć jakby tylko do tej gałęzi jakąś tylko
do przodu.
I takie edycje historii powinny pojawiać się tylko w bardzo krytycznych sytuacjach gdy jest to potrzebne.
O pracy zespołowej powiemy sobie jeszcze więcej w następnych lekcjach pokażę także jak git rebase działa właśnie
przy pobieraniu wysyłaniu zmian na serwer.
Ale o tym wszystkim już w kolejnych lekcjach.
Do zobaczenia.