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 poprzednich lekcjach dowiedziałeś się jak przy użyciu polecenia git reset.
Możesz cofać się w historii tak czyli zmieniać historię oraz dzięki poleceniu git reflog możesz odnaleźć zagubione
inne odgałęzienia historii i przywrócić z powrotem stan do tych commitów które że tak powiem były przed
zresetowaniem historii jest jeszcze jedno bardzo fajne polecenie.
Mianowicie jest to git rebase i polecenie git rebase służy do przeniesienia commitów z jednego miejsca
do drugiego.
To znaczy że mogę wiele commitów przenieść w inne miejsce i na razie naszym jedynym miejscem w którym pracujemy
jest master.
W kolejnych lekcjach zobaczysz jak przenieść commity między gałęziami korzystając z polecenia rebase.
Natomiast w tej lekcji chciałbym ci pokazać jeszcze jedno bardzo przydatne zastosowanie polecenia rebase.
Spójrzmy może najpierw na git log.
i w tym momencie mamy przywróconą naszą historię oryginalną czyli taką którą mieliśmy przed naszymi
porządkami.
Czyli mam tu ten lepszy commit.
Mamy tutaj reverty czyli przywrócone zmiany jak pamiętasz poleceniem git revert które tworzą nowe
commity do odwrotnych.
Mamy tutaj przywrócone pliki txt czyli przywracamy pojedyncze pliki przy użyciu polecenia git
checkout.
I w tej historii jak widzisz mam dość duży bałagan przez te wszystkie przywracania i poprawiania i jak wiesz mogę
tutaj cofnąć się poleceniem git reset z opcją soft i jeszcze raz commity połączyć w jeden nazwać jeszcze raz
i zrobić porządek.
Nie polecam wszystkich commitów łączyć razem w jeden wielki.
Tylko faktycznie warto mieć historię gdzie byśmy krok po kroku widzieli jakie zmiany powstawały w naszym
projekcie.
Jednak ważne żeby ta historia była czysta.
To znaczy żeby nie mieć jakichś długich przypadkowych testowych opisów które nic nie mówią.
Więc czasem warto cofnąć się i poprawić tutaj wiele commitów i w tej lekcji pokażę ci nie tylko jak poprawić
opis tych commitów jak cofnąć się i zmienić wcześniejsze commity ale także jak np. jak zmienić ich
kolejność jak połączyć dwa wcześniejsze commity w historii oraz jak przetestować łatwo pomiędzy commitami
przed lub po zmianach czy przypadkiem coś nie przestało działać jak robić jakieś np. testy które sprawdzą
czy nasz projekt jest w poprawnym stanie czy nie ma tam żadnych błędów.
Jeśli jestem teraz na naszej gałęzi master i ta gałąź master nie jest połączona żadnym serwerem są to tylko
lokalne repozytorium tak jak właśnie utworzyliśmy tutaj w naszym projekcie.
To polecenie git rebase.
Samo w tym momencie praktycznie nic nie zrobi.
Widzisz on się pyta o zdalną gałąź zdalnych gałęziach.
Będziemy też rozmawiać chciałbym żebyś pamiętał że jeśli podasz polecenie git rebase w ten sposób to on chciałby
nasze tutaj commity umieścić po commitach które znajdują się w danym branchu.
Czyli przesunąć nasze commity jakby do przodu.
Nie mamy zdalnego brancha chciałbym mieć jakiś jeszcze inny branch inną gałąź na którą mu przesunąć.
Ale zastanówmy się co by się stało gdybym ja te commity stąd zabrał i umieścił z powrotem w to samo miejsce
spróbujmy git rebase i powiedzmy wezmę sobie z trzy commity czyli git rebase 3 z tej naszej gałęzi master trzy commity i odłożę
je z tu z powrotem.
I jak mógłbyś się domyślić efekt jest praktycznie żaden.
To znaczy faktycznie zdjąłem te commity i włożyłem w to samo miejsce i pod takie polecenie.
W ten sposób nic nam to nie daje ale jeśli wykonam to polecenie.
Jeszcze raz ale dodam tutaj parametr interactive lub w skrócie po prostu myślnik i chciałbym żebyś zapamiętał freebase i
Base i.
I podaje commit tutaj na przykład pierwszy drugi trzeci czyli te trzy commity chce rebase czyli zmienić
jakby bazę od tego punktu chce te trzy commity zdjąć interaktywne zdecydować co z nimi zrobić i potem
odłożyć je z powrotem w to samo miejsce.
Po wprowadzeniu zmian i teraz jakich zmian zobaczmy wykonam polecenie git rebase.
Minus i czyli interaktywne trzy commity do tyłu i takie polecenie zdejmie mi trzy commity na bok.
Takich jest dużo to polecenie może chwilę zająć.
I tutaj mam taką listę to do czyli jak widzisz git nam utworzył plik git rebase to do.
I pyta nas co zrobić i zobacz.
Mam bardzo fajne narzędzie bo mogę nie tak jak poprzednio poleceniem checkout i reset pracować tylko
na pojedynczych commitach.
Tylko mogę tutaj wykonać wiele operacji jedna po drugiej jakby zaplanować wiele zmian korzystając właśnie
z jednej operacji czyli np. mam tutaj pick i pick zostawi commit tam gdzie jest.
Czyli mam tutaj trzy razy pick ustawione już czyli w tym momencie to polecenie commity zdjęło i każdy
z tych commitów.
Potem odłoży.
Zwróć uwagę na kolejność git log wyświetliłby mi tych commitów w odwrotnej kolejności czyli na samej górze byłyby najnowsze
i by leciały w dół do coraz starszych tutaj kolejność jest odwrotna.
Najnowszy commit jest na samym dole a poprzednie coraz wyżej aż tutaj do najstarszego i dlaczego w ten
sposób wyświetlone.
A dlatego że to polecenie jak widzisz będzie odkładało z powrotem te commity w tej kolejności.
Mam trzy razy pick czyli trzy razy z tej bocznej że tak powiem kupki od różnych commitów z powrotem.
Wejść wejść wejść trzy commity w tej kolejności i spróbujmy teraz wykonać dokładnie taką operację czyli
umieść je w tej kolejności czyli zrobię escape dwukropek wq czyli tak samo jak commitowaliśmy i dodawaliśmy message do
edytora tutaj vim tak samo poleceniem escape wq.
Ja mogę zapisać ten plik git rebase to do i o tym gdy git go odczyta i wykona te polecenia spróbujmy
chwilkę.
Widziałeś było rebasing mam successfully rebased and updated.
I git log.
Jak widzisz tutaj mamy dokładnie to samo czyli zdjąłem te polecenia odłożyłem je z powrotem ale jak widziałeś
tam miałem różne polecenia mogłem zrobić dużo więcej rzeczy w trakcie czyli w momencie gdy będzie odkładał
odkłada po kolei i wykonuje operacje.
Spróbujmy teraz wykonać coś bardziej praktycznego zaplanujmy coś co chcemy zrobić.
Mamy tu lepszy commit i właściwie mogę się go pozbyć tak jak poprzednio się go pozbyłeś przy użyciu reseta mam
dwa reverty i może na początek ćwiczenia po prostu obróćmy miejscami dlatego że one dotyczą różnych plików.
Plik witaj txt to jest notatka więc spróbujmy je dla ćwiczenia zamienić kolejnością tu mamy plik przywrócono plik
witaj txt i nowa linia witaj txt jakiś.
Oba te commity dotyczą pliku witaj txt.
Więc spróbujmy je połączyć razem ze sobą i może na tym zatrzymamy nasze ćwiczenie.
Czyli tak mógłby robić git rebase.
Interactive head tylda 1 2 3 4 5 albo mogę podać tutaj commita nie podaje tutaj tego commita który
jeszcze chce na nim operować.
Będzie to z rebase czyli zmiana bazy czyli jako polecenie muszę podać tutaj od którego commita i ja
chcę poprawić jeszcze te wszystkie wyżej czyli mamy dodano witaj witaj i wcześniejszy jest ten OK czyli spróbujmy
zrobić git rebase i i od tego commita który był przed naszym witaj.
Naszą zmianą witaj txt.
OK.
Czyli mamy tutaj lepszy commit mamy nasze dwa reverty i mamy tutaj dwie zmiany w witaj i teraz zobacz
będziemy aplikować zmiany od najstarszych do najnowszych.
Co prawda ja mogę właśnie dzięki temu że widzę wszystkie pliki od razu ja mam pełen obraz sytuacji i mogę zacząć
od samego dołu.
I tu powiedzmy wcisnę a albo insert żeby być w trybie edycji w edytorze i tutaj pick zamienię na drop bo
chce się całkowicie pozbyć tego commita.
Jeśli np. zamiast pick mogę zrobić d krócej abym mógł po prostu nie mieć tego commita w ogóle commity które pominięto
tutaj są nie odłożone z powrotem czyli też zostaną usunięte z poleceniem.
D jak drop żebyśmy tutaj widzieli co się dzieje jeśli chodzi o te dwa polecenia.
Ja tu chciałbym je zamienić kolejnością więc tu w edytorze vim możesz bardzo prosto poleceniem dd może escape najpierw
dd wyciąć linie i poleceniem p umieścić po prostu wiersz niżej czyli z odwrotną kolejność mamy najpierw
notatka przeczytaj to a później przywrócono plik witaj txt tutaj wyżej mam dwa commity i chciałbym
je połączyć razem ze sobą i teraz mam dwa polecenia mamy polecenie squash i polecenie fixup i teraz polecenie
squash połączy nam te commity ale w taki sposób że oba message czyli ten tekst i ten tekst zostaną umieszczone
jako nowe message tego commita ja chcę zrobić troszeczkę inaczej.
Chciałbym połączyć je ale w taki sposób żeby tylko zostawić jeden message.
Czyli spróbujmy się zatrzymać i powiedzmy pick.
Weźmy ten a ten połączymy z poprzednim
czyli a usunę i wybiorę sobie nie polecenie squash tylko polecenie fix f lub fix i w ten sposób
ten commit zostanie połączony z poprzednim commitem.
Ta wiadomość zostanie u góry ta zostanie utracona.
Te zamieniają kolejność.
Te są połączone.
Ten jest usunięty.
Zobaczymy czy to faktycznie zadziała.
Czyli te dwa łączymy te zmieniamy kolejnością ten usuwamy jako efekt powinniśmy mieć 1 2 3 commity w
tej kolejności.
Witaj notatka przywrócono witaj a właściwie git log pokażemy w odwrotnej kolejności czyli pokaże witaj tutaj
witaj.
Przeczytaj to i dopiero pokaże nasz połączone.
Nowa linia witaj txt.
Z tym lepszym commitem będziesz miał problem że jest to ostatni commit.
Więc jeśli masz ostatni commit i tego nie chcesz zmienić tylko zupełnie usunąć to nie wiem czy mu na takie coś pozwoli
ale spróbujmy.
Tutaj też chciałbym żebyś zobaczył że to jest bezpieczne że z tego będziesz mógł się wycofać.
Zrobię tutaj wq pozwolę mu zrobić sobie tego rebase'a o i mamy tutaj błąd.
Mamy problem tutaj mamy polecenia dwa wykonane czyli tak chce zaaplikować nową linię chciał przywrócić nową
linię.
I tutaj mamy następne trzy polecenia do wykonania
i taki błąd że próbowałem poprawić commit ale robiąc to commit będzie pusty.
Możesz powtórzyć z poleceniem allow empty albo możesz usunąć ten commit z poleceniem git reset head.
Czyli widzisz gdy coś jest nie tak.
To on się zatrzymuje i mówi że nie mógł tutaj zaaplikować.
Przywrócono plik witaj txt czyli tutaj jest przywrócono plik witaj txt.
No właśnie czyli ten commit jak pamiętasz on odwracał.
Poprzedni commit zwróć uwagę jesteśmy w trakcie rebase'a pokazuje że jesteśmy na gałęzi master
ale jesteśmy w trakcie rebase'a dwa z pięciu commitów czyli na tym drugim już commicie.
Mamy problem z przywrócono witaj txt i to jest bardzo fajna rzecz bo ja mogę sobie zrobić git status i tutaj
jesteśmy w trakcie edycji tego commita czyli teraz jeśli ja wprowadzę jakieś zmiany i scommituje tutaj
powiedzmy jesteśmy przywrócono mam kilka opcji.
Mogę robić git rebase edit todo i jeszcze raz podejrzeć mój cały listę operacji do wykonania mogę zrobić
git rebase i continue
I to jest właśnie jakbym scommitował ten plik txt.
Czyli jakby ręczną edycję i kolejną operację który po tej wykona zobaczmy co tu się stało.
Git status jeszcze zobaczymy albo git show.
Zobaczmy ten commit w którym ma on problem.
On usuwał te dwie linie i dodawał tą linię witaj świecie ok spróbujmy git rebase continue czyli
niech on tą zmianę zaakceptuje zobaczymy czy się to uda
ok.
I zapyta się jak ma się nazywać ten commit tutaj umieścił mi właśnie
jakby kombinację dwóch commitów ale że wybrałem opcję jak pamiętasz nie squash tylko fix tutaj to drugi commit.
Druga message jest zakomentowana.
Czy on niej nie umieści jeśli nie odkomentuje byłaby tutaj opcja s no to wtedy obie linie połączył by w jeden
commit a komentarzem stąd usunął ten komentarz.
Nowa linia txt jest OK spróbujmy tutaj opisać to leci dalej rebase 4 rebase 5 skończył gdybyś chciał przerwać anulować
całkowicie wystarczyłoby żebyś zrobił git rebase myślnik myślnik abort
i całość cofnęła by się z powrotem do miejsca przed rebasem i mógłbyś zrobić tutaj
jeszcze raz ja zrobiłem continue czyli chciałem przejdę do kolejnego kroku zaakceptowałem tutaj jego rozwiązanie.
Spróbujmy git log i teraz pozbyliśmy się ostatniego tego commita naszego nowego commita.
Te commity odwróciły w odwrotnej kolejności są umieszczone na tutaj niestety w dół gdzie był problem.
Tam gdzie się zatrzymaliśmy.
Zapytał nas żeby stworzyć nowy commit.
I tu widzisz mam dwa commity które nazywają się tak samo.
Spróbujmy to jeszcze naprawić.
Czyli chce się cofnąć jeszcze raz tu git.
Rebase Interactive do tego miejsca
i taki jest problem który nie pozwolił nam wykonać poprzedniego.
Rebase'a że te dwa comity będą przeciwne ponieważ mieliśmy komitet który dodawał linie w pliku witaj txt
i commit który tą linie usuwał.
Jeśli zobaczysz jeśli jedna zmiana dodaje linie a druga ją usuwa jeśli połączysz oba zmiany w jedną zmianę.
Commit który praktycznie nic nie robi tak mieliśmy poprzednio nazywał się nowa zmiana.
A tutaj miało revert nowa zmiana więc co zrobię to po prostu pozbędą się obu tych commitów.
Tu mamy tylko te dwa reverty spróbujmy wq
mamy successfully w rebased.
Oneline czyli się pozbyłem tych ostatnich zmian.
Zobaczmy jak wygląda sytuacja w witaj świecie i mam poprzednią sytuację jeszcze jest jeszcze jedna linia
w pliku.
Czyli to co nam robiło ostatni ten commit był usunięty i te dwa commity przeciwne dodawały usuwany
zostały także usunięte.
I tak mamy przywrócone notatki.
Te dwa commity możemy też spróbować połączyć.
Czyli jeszcze spróbujemy zrobić git rebase interactive head
2.
I to jest prawda.
Jeden plik edytuje
notatki a drugi witaj txt.
Ale może spróbujmy zrobić tak że ten pierwszy zmienimy mu opis czyli reword a drugi po prostu połączymy
z poprzednim i usuniemy jego opis to byśmy mieli jeden commit który nazwiemy teraz jeszcze raz od nowa.
Ok.
I tu widzisz jest bardzo długi opis dwie linie z tym revertem.
Więc ja mogę się pozbyć poleceniem td czyli wyciąć oba te opisy i dać jeszcze nowy.
Po prostu inaczej usunę ten i korzystając a albo insert na klawiaturze mogę teraz wpisywać i wpiszę po
poprawiono
notatki.
I witaj txt escape w i q czyli write i quit.
OK.
Jak widzisz pozmienialiśmy zupełnie całą strukturę historii.
Pozmienialiśmy kolejność nazwy dodaliśmy ustaliliśmy commity jak widzisz git rebase na tej samej gałęzi na której
jesteśmy.
Pozwala właśnie zmieniać historie interaktywne czyli różne operacje.
Pozwala nam zaplanować następny krok po kroku odtwarza tę operację i jeśli gdzieś popełniliśmy błąd
chcielibyśmy żeby zrobił coś co nie jest w stanie zrobić albo ma wątpliwości to zatrzyma się i zapyta
co dalej możemy poprawić pliki jeśli wszystko jest OK.
Robimy git rebase continue.
Ja tą zmianę aplikuję jako osobny commit i idzie dalej.
Jeśli nam się coś nie podoba robimy git rebase abort.
I on nas cofa z powrotem do miejsca w którym byliśmy.
Jeśli popełniłeś naprawdę jakiś duży błąd i już skończyłeś tego rebase'a to pamiętaj czego nauczyłeś się w lekcji
o poleceniu git reset.
Po prostu korzystając z git reflog
ja tu mogę po tych wszystkich naszych rebase'ach cofnąć się jak widzisz każdy commit w rebase zmieniony
dodaje kolejnego refloga.
Jest tu bardzo łatwo sobie zrobić bardzo dużą historię przy kilku takich rebase'ach.
Ale jeśli przejdziemy troszeczkę niżej to tutaj gdzieś powinien być nasz reset.
Który nas przeniesie do poprawione notatki
tutaj pamiętasz przesuwaliśmy się do pozycji 23.
Czyli jeśli przywrócę ten commit git reset czyli jeśli z powrotem wrócę do tej właśnie opcji 23 git status
z ostatnich naszych merge'ów zmiany natomiast git log
jak widzisz wszystkie zmiany które dokonaliśmy możesz w każdej chwili przywrócić korzystając z git reset.
Jeśli chce powrócić z powrotem do tego naszej operacji po git rebase no to to git reset.
Head i tu będzie w ten sposób 1.
Jeszcze raz git log i mamy sytuację przed naszymi poprawkami sytuacje po naszych poprawkach.
Czyli jak widzisz polecenia git reset git reflog git rebase one wszystkie pozwalają Ci dowolnie modyfikować
operować na historii na jednym commicie na wielu commitach wykonać różne operacje na różnych commitach
a gdy cokolwiek pójdzie nie tak.
Możesz w każdej chwili po prostu zobaczyć reflog i przywrócić się przywrócić całą swoją historię do poprzedniego
stanu.
I jeszcze jedną fajną opcją jest polecenie execute czyli jeszcze raz wykonam powiedzmy git rebase head
no to powiedzmy tylko tylda trzy.
Oczywiście tryb interaktywny
i jeśli pomiędzy twoimi poleceniami mimo to mamy trzy razy pick ja nic nie będę zmieniał ale np. jeśli masz
aplikację i może się zdarzyć że to pomiędzy tymi commitami może wprowadzona jakaś zmiana albo git w jakiś dziwny
sposób połączy te commity sposób który nie do końca przewidziałeś i chciałbyś właśnie zobaczyć czy po każdym kroku czy
przypadkiem właśnie git gdzieś nie popsuł Twojej aplikacji.
To jest bardzo fajna możliwość tutaj jak widzisz jest opcja z x lub exec i ona pozwala uruchamiać polecenia przy użyciu shella czyli wbudowanego
w terminal systemowego i w ten sposób możesz po każdym kroku albo w wybranych krokach uruchomić polecenie
które sprawdzi czy aplikacja jest w stanie czy ona działa.
Czyli np. tutaj jest jeśli takie polecenie zwróci zero czyli bez błędów się zakończy.
No to tutaj będzie on kontynuował jeśli to polecenie zwróci jeden czy wyświetli jakiś błąd no to on powinien przerwać
tę operację i teraz ja może jeszcze wyjdę z tego na razie q niech on tu zrobi po prostu nic i przekopiuję
mam sobie takI skrypt tutaj.
Run tests i tutaj powinien być taki właśnie run tests.
Jest to taki prosty najprostszy skrót bashowy który będzie sprawdzał czy plik jaki mu podam czy ścieżka
do pliku czy ona istnieje jeśli istnieje to widzimy komunikat że plik istnieje i zwróci kod 0 czyli
wszystko w porządku.
Jeśli plik nie istnieje no to zwróci tutaj jeden i komunikat że plik nie istnieje spróbuję go tutaj wykonać czyli zrobimy
sobie tak
run tests i sprawdzę czy plik witaj istnieje a plik witaj 2 powiedzmy nie istnieje.
I teraz możesz taki skrypt który ma być bardziej rozbudowany może być to skrypt który uruchamia inne aplikacje
inne testy sprawdza czy twoja aplikacja działa poprawnie.
Możesz go wykonać w trakcie wykonywania rebase'a możesz zrobić tutaj git.
Rebase head 3 i mogły już polecenia exec i podać właśnie takie polecenie czyli run tests i witaj txt.
Może w ten sposób jak widzisz tutaj on wykonuję przy każdym kroku nasz test
i tylko rebase się zakończy poprawnie.
Jeśli za każdym razem zwróci tutaj pozytywny czyli zero jeśli zbada czy witaj np. 2 istnieje to powinien
przed rebasem.
O widzisz i mam sytuację taką że spróbował wykonać nasze testy.
Nasze testy zwróciły 1 czyli kod błędu i mam informację że execution failede i dokładnie na jakim poleceniu
czyli też mógłbym różne polecenia sobie podawać i dokładnie podać co się stało.
I najważniejsza rzecz.
Zwróć uwagę że on nie przerwał nam całego rebase'a tylko tak jak byśmy mieli błąd przy rebase'owaniu albo
gdybyśmy zrobili po prostu w pewnym miejscu jako polecenie edit.
On tutaj zatrzymał się na kroku drugim z sześciu czyli przed w trakcie wykonywania drugiego kroku tutaj już się
zatrzymał i mam opcję tak jak poprzednio.
Wpiszę git status mogę wykonać git rebase continue stwierdzić ok błąd nie jest nie istotny.
To działa kontynuujemy mogę zrobić abort.
Mogę też.
Jak widzisz w pliku w dowolnych moich plikach wprowadzić zmiany i zrobić git commit amend.
Czyli mogę poprawić ten commit.
Nim go odłożymy z powrotem na naszą bazę mogę go poprawić i scommitować jeszcze raz mogę tutaj jeszcze
edytować naszą listę czyli git rebase edit todo i na chwilkę wrócę do tego git rebase edit todo
skoro i tak już rebase'ujemy i tutaj jak widzisz ten exec.
Dopisany został do listy poleceń czyli ja mogę tutaj zmienić sobie z powrotem na witaj.
Czy jak widzisz testy można wykonywać także tu i nie muszę tego testu wykonywać w każdej linii np. mogę
wykonać ten test powiedzmy tylko po drugim commicie.
Po trzecim już nie będę go chciał wykonywać wykonam go tylko raz i tym razem poprawnie zapisz i tu on
jeszcze raz będzie kontynuował od drugiego.
I teraz cały czas jesteśmy w trybie zatrzymanym 2 na 6 i mogę kontynuować git.
Rebase continue.
Poleciał dalej.
Wykonał test tym razem poprawnie.
Rebasing i wszystko powinno się zakończyć prawidłowo.
Miałem same picki więc tu właściwie zmian żadnych nie robiliśmy.
Ale jak widzisz możesz w każdym kroku wykonać automatyczne testy więc jeśli robisz bardzo duże rebase'y.
Albo rebase'ujesz np. czyjeś zmiany czyjeś zmiany i nie chcesz każdego commita uruchamiać ręcznie sprawdzać klikać czy
wszystko działa.
Proste testy automatyczne które sprawdzają czy twoje aplikacja przypadkiem się nie popsuła czy wszystko
działa prawidłowo.
Takie coś szczególnie się przydaje gdy twoja aplikacja korzysta z test driven development czyli do każdej
funkcjonalności dopisane są testy automatyczne takie testy jak widzisz możesz uruchomić po każdym commicie dzięki
czemu masz pewność że taki rebase przypadkiem nie połączy jakichś commitów w zły sposób i nie będziesz
miał uszkodzonej aplikacji.
I pamiętaj zawsze gdy coś pójdzie nie tak przy edycji historii możesz skorzystać z polecenia git.
Reflog.
Odnaleźć tutaj ostatnią naszą sytuację gdzie wszystko wyglądało jeszcze w porządku prawdopodobnie będzie
to gdzieś tu na ostatnim resecie i przywróci z powrotem wszystkie zmiany przed rebase'em i zacząć jeszcze
raz to na tyle jeśli chodzi o rebase'a na jednej gałęzi w przyszłych lekcjach.
Dowiesz się jak rebase pozwala commity przekładać przestawiać pomiędzy różnymi gałęziami a także pomiędzy
gałęziami z danymi na np. serwerze który śledzimy z naszego mastera.
Ale o tym wszystkim już w kolejnych lekcjach.
Do zobaczenia.