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 w naszym projekcie w naszych plikach powstało już dużo zmian i powstała też historia
zmian w postaci naszych commitów.
Jak pamiętasz z poprzednich lekcji korzystając z polecenia git log możemy podejrzeć taką ostatnią historię naszych
zmian w tej lekcji.
Powiem więcej o poleceniu git log pokaże jakie dodatkowe opcje i parametry przyjmuje aby można było łatwo
wydobyć informacje z historii zobaczyć kiedy powstały jakie zmiany w jakich plikach.
Kto tych zmian dokonał a także pokaże ci jak korzystając z różnych opcji i parametrów polecenia log
sformatować lub zaprezentować tą właśnie historię zmian w taki sposób by ona była jak najbardziej użyteczna i czytelna
jak widzisz domyślnie polecenie git log bez żadnych parametrów wyświetla listę ostatnich zmian zaczynając
od najświeższych czyli takich którą wykonaliśmy ostatnio i po kolei do coraz starszych zmian.
I tutaj mamy.
Każdy element zawiera commit hash zawiera autora wraz z emailem zawiera datę scommitowania i zawiera message czyli komunikat
opis tego szczególnego commitu i poszczególne zmiany które nas interesuje i ten opis jest taki bardzo dokładny.
Mamy też dużo informacji nie zawierają treści zmian ale mają informacje kto kiedy i informacje co zostało
zmienione.
Czasem jednak chcemy zaprezentować te dane w innym formacie na przykład gdy tych commitów jest bardzo dużo.
My mamy akurat ich sześć czy nawet jeszcze nie mamy ich tylko pięć jest wszystko jest czytelne.
Jeśli mam bardzo dużo komików i chciałyś je zaprezentować jeden po drugim w nieco bardziej zwartej formie
to możemy zrobić to jeszcze raz użyć polecenia git log i dodam opcję one line.
Jak widzisz mam tutaj bardzo krótki zwarty opis.
Mamy tylko skrócony hash czyli fragment początek naszego hasha do porównania wyświetla git log pełen opis.
Mam tutaj pierwsze bodajże 6 8 zobaczmy raz dwa trzy sześć siedem pierwszych znaków tutaj naszego identyfikatora i następnie mamy samą wiadomość.
Jeśli interesuje Cię sama wiadomość chciałbyś tylko podejrzeć właśnie któryś commit w ten sposób no to właśnie taki one-linem się pisze w
bardzo wygodny szczególnie gdy tych commitów jest bardzo bardzo dużo.
Mając taki krótki hash ja mogę sobie go tutaj pożyczyć i poleceniem git show mogę tu już podejrzeć bardzo szczegółowy
opis nie tylko mam tutaj pełen hash commita który sobie wybrałem mam też autora datę.
Mamy też message a następnie poniżej mamy różnice do różnic jeszcze wrócimy ja chciałem jeszcze opcje oneline czyli
jak widzisz jeśli chce tylko znaleźć commit dopiero po jego ID dowiedzieć się więcej a tu chcę mieć tylko
właśnie najkrótszą listę to polecenie oneline.
Zapisuje to w takim formacie mamy także do wyboru kilka innych formatów mianowicie poleceniem git
log myślik myślinik format mogę tutaj wybrać kilka innych formatów m.in. oneline.
I jak widzisz jest to format bardzo podobny do poprzedniego.
Jedyną różnicą jest to że tutaj mamy pełne hashe tak mamy także format short.
I tu mamy krótszą opcję mamy tylko hash autora i message.
Jeśli nas interesują to ta opcja short jak widzisz jest bardzo przydatna.
Mamy opcję medium jest troszeczkę więcej.
Mamy już datę i to jest jak widzisz bardzo podobne do domyślnego formatu który po prostu bez żadnych parametrów.
Mamy tutaj bardzo podobny format.
Idąc dalej jest format full.
I tu jeśli interesuje Cię różnica między autorem commita a faktycznie osobą commitującą no to format
full właśnie wyróżnia te dwie rzeczy natomiast format fuller idzie jeszcze o krok dalej.
Czyli tu mamy informację o autorze i dacie oryginalnego utworzenia i dacie scommitowania.
Nasz pierwszy commit.
Jeśli dobrze pamiętasz.
My go poprawiliśmy jak widzisz autor jest ten sam ale data i godzina się różnią dlatego że ten commit był
jakby zmieniany był zmieniany
jego autor także oneline short medium full i fuller są to jakby gotowe już opcje formowania dostępne w git log.
Mamy także inną możliwość zamiast podawania tutaj nazwanego gotowego formatu ja mogę podać tutaj własnoręcznie
przygotowany ciąg znaków formatujący właśnie poszczególne wyniki a korzystając z tak zwanych placeholderów
czyli takich specjalnych stawek zaczynających się od znaku procenta.
Mogę właśnie wskazać w którym miejscu git log ma wstawić odpowiednie dane np. wpisze sobie tutaj commit
i tutaj dolar s będzie oznaczało ciąg znaków opisujący nasz commit czyli nasz message.
Dodatkowo powiedzmy w nawiasach umieszczę sobie tutaj procent H.
Czyli to będzie oznaczało nasz hash naszego commita a dodatkowo powiedzmy jeszcze dodamy tutaj an czyli
author name powiedzmy tutaj po myślniku.
Jak widzisz wpisując w ten sposób dostałam tutaj listę wyników które dokładnie spełniają wzorzec format
który podałem.
Czyli jak widzisz każdy wynik zaczyna się od słówka commit mam następnie nasz message czyli treść opis naszego
commita w nawiasach np. podałem tutaj sobie hash i potem autora.
Nie jest to bardzo czytelne.
Może spróbujmy wprowadzić parę zmian usunę na początku ten commit i powiedzmy że przeniosę tutaj hash
na początek czyli spróbujmy hash opis jak widzisz jest to już dużo czytelniejsze.
Tego że tutaj długość tych hash jest taka sama więc mamy ładny tableczny format.
Autor tutaj na końcu jest bardzo nieczytelny.
Dlatego że długości tego komunikatu są różne.
Spróbujmy jeszcze to poprawić i np. przeniosę autora wcześniej autor name umieszczę tutaj
jak widzisz mamy teraz bardzo fajny czytelny format mamy hash mamy tutaj naszego autora i mamy komunikat.
Jeśli chciałbyś wiedzieć jak formatować tutaj dowolnie Twoje wiadomości w git log znać po kolei te wszystkie
różne placeholdery czyli wstawki to ja nie będę ich omawiał bo jest ich bardzo bardzo dużo.
Są tutaj różne możliwości w różnych sytuacjach i tobie też nie polecam znać ich wszystkich na pamięć.
Może kilka podstawowych jeśli potrzebujesz na szybko przeważnie jeśli konstruujesz jakiś raport czy jakieś
poszukujesz konkretnych informacji no to na spokojnie można taki format skonstruować korzystając z dokumentacji.
I tu ponownie odwołam się do git log myślnik myślnik help czyli do opcji help czasami przy każdym
poleceniu.
To otworzy mi tutaj w przeglądarce nową stronę i na tej stronie poszukam czegoś takiego jak pretty formats
tutaj w sekcji dokładnie pretty formats.
Jak widzisz masz zarówno wymienione informacje o tych wbudowanych formatach a jak przewijać troszeczkę
niżej.
To jak widzisz masz opcję wszystkich dostępnych placeholderów.
Masz mały duży hash czyli ten pełny 48 znaków masz skrócony unikalny hash masz author name author email.
Są także daty autora daty commitującego treść komunikatu i masa różnych opcji są tu nawet różne rzeczy o których
jeszcze nie mówiliśmy.
Dlatego ja ich nie będę omawiał polecam tobie popróbować tworzyć sobie różne komunikaty a gdy będziemy opowiadać
sobie już o nowych funkcjonalnościach o pracy zespołowej także polecam tobie wrócić do git loga i zobaczyć jak możesz
przejrzeć zobaczyć różne rzeczy różne zmiany które wprowadziliśmy powiedzmy na gałęziach i wyświetlić
je sobie przy pomocy tutaj polecenia git log z opcją format.
Tak więc wiesz już jak sformować dowolnie nasz git log czyli wiesz jak wyświetlić takie komunikaty w
takim formacie jak potrzebujesz.
Jednak nie zawsze będziemy pracować z pełnym logiem gdy tego loga będzie bardzo dużo czasami da się obejrzeć
tylko kilka wyników lub odfiltrować tylko te wyniki które nas interesują.
I teraz pierwszą rzeczą którą moglibyśmy zrobić to ograniczyć liczbę wyników czyli nie chcemy koniecznie
wszystkich tylko chciałbym np. n pierwszych wyników czyli powiedzmy n 2.
Jak widzisz dwa najnowsze pojawiły mi się wyniki.
Jeszcze krócej mogę napisać to po prostu podając jako parametr liczbę wyników.
Jak widzisz samo myślnik 2 podał mi 2 1 wyświetla mi 1 commit a 4 dostaniemy 4 i tak dalej.
Mamy też jeszcze jedną fajną opcję powiedzmy że chce się mieć dwa commity ale nie chcę zaczynać od
ostatniego.
Tylko chcę dwa pominąć.
Czyli podam opcję skip pominę dwa ostatnie i wyświetlę 2.
Jak widzisz mamy tutaj dwa ale jeśli porównam to widzisz są to różne commity dlatego że pierwszy tutaj sytuacja nam się wyświetliła
dopiero od drugiego kolejne dwa a w drugim przypadku mamy ostatnie dwa od ostatniego który stworzyliśmy.
Jak widzisz możesz sobie korzystać z poleceń.
Tutaj po prostu myślnik i liczba oraz polecenia skip przesunąć jakby to okno wyników od do ustalić od którego momentu
i ile jeszcze chcesz wyników wyświetlić.
O ile polecenia tutaj skracające liczbę wyników są bardzo przydatne jeśli po prostu ich dużo i chcemy ich wyświetlić
troszeczkę mniej o tyle nie są zbyt praktyczne jeśli chcemy znaleźć konkretne interesujące nas informacje.
Czyli tutaj git log.
Jeszcze raz i powiedzmy że chciałbym wyświetlić tylko te commity które były stworzone tutaj przed 10 marca piątek
to mamy jeszcze taką fajną opcję git log.
I mogę podać opcję before czyli stworzone przed i podać datę.
I tutaj mamy kilka różnych formatów dat najdokładniej byłoby podać 2017 tutaj miesiąc
czyli zero trzeci i dziesiąty dzień jak widzisz nie ma tutaj tym razem wszystkich commitów czyli mamy ich tu
ignorujemy
katalog z logami tylko tutaj podając datę.
Jak widzisz pierwszym moim wynikiem jest dodano folder notatki jak widzisz tutaj mamy datę 11 mamy datę 11 tu mamy datę 10.
Nasze wyniki zaczynają się dokładnie od tej daty.
Oczywiście mogę taką opcję połączyć np. z opcją tutaj 1.
Czyli jak wiesz mogę wybrać pierwszy commit a właściwie ostatni commit który był utworzony przed datą 2017
03 10.
Mamy też drugi fajny parametr mogę zrobić tutaj zamiast before mogę podać after czyli wszystkie commity
które były utworzone po dacie 3 10.
Jak widzisz mam w wynikach tylko wyniki tylko commity które były utworzone 11 marca.
Możesz podać w takim formacie.
Można tutaj podać dokładnie git log powiedzmy after
i chciałbym tutaj podać dokładną datę czyli tak w cudzysłowiu podam 2017 miesiąc marzec
11.
I tutaj korzystając z formatu ISO 8 6 01 bodajże musimy rozdzielić datę od czasu słówkiem t i teraz
tutaj mogę podać dokładną godzinę czyli wszystko co było po godzinie 15.
11 marca 2016 ma być wyświetlone jak widzisz już dokładnie znaleźć commity pomiędzy after i jednocześnie mogę podać before.
Czyli możesz dwoma datami dokładnie określić zakres ile commitów potrzebujesz.
Dodatkowo możesz także cały czas korzystać z formatu np. oneline czyli możemy różne opcje łączyć żeby
znaleźć dokładnie te commity które cię interesują i wyświetlić je w taki sposób jak potrzebujesz oczywicie taką ilość jaką
cię interesuje jaka jest ci potrzebna.
Każdorazowe podawanie dokładnej daty i godziny aby wyszukać nasze commity w czasie nie jest powiedzmy najwygodniejszą
metodą powiedzmy że pracujesz już 2 tygodnie nad jakimś projektem i pamiętasz że powiedzmy dwa tygodnie
temu wprowadziłeś jakieś zmiany wchodzenie teraz w kalendarz i szukanie dokładnie jaki to był dzień
jak data jak godzina.
Dwa tygodnie temu.
Nie jest najwygodniejsze dlatego tutaj git log zarówno w opcji before oraz w opcji after spróbujmy tutaj after mogę podać
taki ludzki format czyli np. jeden week ago.
A zróbmy od razu two weeks ago.
I jak widzisz git rozpoznaje świetnie taki format jeśli wpisze powiedzmy one week ago.
Czyli prawidłowo tutaj zmienię.
To nie mamy żadnego wyniku mogę też wyłączyć tę opcję mogę spróbować one week i powiedzmy five days
ego.
Jak widzisz te opcje znajduje mi tylko dwa commity i możesz takie opcje łączyć mogę użyć zarówno tutaj after
mogę użyć jednocześnie z before I mogę podać różne warianty mogę podać tydzień miesiąc dzień rok.
I tutaj prawidłowo.
Na podstawie tego wzorca względem aktualnej daty jaką mam ustawioną w systemie wyszuka nam wszystkie
commity.
Jak przyznaje jest to dużo wygodniejsza opcja niż podawanie dokładnej daty chyba że właśnie taką datę
posiadamy.
Polecam Tobie poeksperymentować zobaczyć czy jeśli masz klika commitów np. nie wiem hours ago minutes ago weeks ago
pamiętaj o przecinku który oddziela poszczególne elementy.
No i na końcu tutaj opcja jeszcze ago często się jednak zdarza.
Szczególnie gdy nasz projekt już od dłuższego czasu jest rozwijany.
Nie wiemy nie pamiętamy dokładnie kiedy zmiana została wprowadzona ani w którym commicie ani nawet
nie wiemy.
Nie znamy dokładnej daty jakiego dnia i godziny zmiana wprowadzona często jest tak że wiemy tylko kto zmianę
wprowadził albo gdzie zmiany wprowadził w którym pliku albo czego zmiana dotyczy jakichś słów kluczowych
elementów naszej aplikacji.
I na szczęście git log posiada tutaj dodatkowe opcje pozwalające właśnie szukać commitów po ich zawartości
po ich treści.
Niektórym chciałem pokazać że jest opcja author i mogę zrobić author Mateusz.
Jak widzisz author Mateusz wyświetla wszystkie logi już
samo imię i to wynika z tego że autor jest wyrażeniem regularnym.
Oznacza to że nie tylko nie muszę podawać całego autora jego fragment ale mogę właśnie zastosować tutaj
wyrażenia regularne żeby określić dokładny wzorzec do którego według którego będzie log wyszukiwał
różnych autorów np. także mógłbym tutaj zastosować domenę i wyszukać wszystkich autorów którzy znajdują
się właśnie w takiej domenie.
Jeśli wpiszę jakąś opcję której nie ma jak widzisz git log nie podaje żadnego autora to żaden ciąg author żaden zapis autor ani
w imieniu ani nazwisku ani w e-mailu nie posiadał trzech znaków x.
Tutaj authorów także możesz podać kilku i wtedy dostaniesz wyniki z listą zawierających jednego drugiego
trzeciego z autorów.
Tutaj na razie tylko ja commitowałem więc nie mamy tutaj za wiele możliwości.
Jak pamiętasz oprócz autora mam też commitującego.
Jeśli chcesz wyszukiwać nie po authorach tylko po osobach które faktycznie tego dokonały to tutaj oczywiście tutaj
oczywiście możesz podać opcję commiter i opcja.
Commiter działa tak samo jak author też z wyrażeniem regularnym ale będzie wyszukiwanała po osobach które scommitowały
a niektóre były oryginalnym authorem commita.
Często zdarza się że wiesz który plik został zmieniony.
Wiesz który plik cię interesuje i chciałbyś znać wszystkie jego modyfikacje chciałbyś znać jego autora.
Chciałbyś zobaczyć historię ale nie całego projektu tylko zobaczyć jak zmieniał się pojedynczy plik
lub grupa plików lub katalog w czasie.
Do tego służy polecenie git log który polecam rozdzielić opcje od ścieżek i w sytuacji gdyby jakiś
plik nazywał się podobnie jak polecenie żeby ci się pomyliło.
Czyli dwie.
Dwa myślniki oddzielą nam wszystkie inne opcje od ścieżek i teraz mogę podać np. opcję logs.
Jak widzisz mam tylko commit który dotyczy naszego katalogu z logami mogę pójść krok dalej i zobaczyć
żeby tylko logs specjalny jest ten sam commit spróbujmy inny katalog np. notatki jak widzisz notatki
były modyfikowane w dwóch różnych commitach jeśli przejadę troszeczkę głębiej i np. wybiorę nie notatkę tylko
notatkę dobra nazwa tutaj jak widzisz określając dokładnie ścieżkę do pliku lub znowu korzystając z jakiegoś wzorca
określając grupę plików katalog lub poszczególne plik lub wzorzec dopasowuje wiele plików jak widzisz
możesz doprecyzować dokładnie wybrać listę commitów która tak powiem oznacza która zawiera zmiany dotyczące
tylko i wyłącznie tego pliku i oczywiście tutaj oneline nie zadziała bo jak pamiętasz rozdzieliłem opcje od ścieżek
i jeśli dodatkowe opcje dodam trzeba podać je przed ścieżką jak widzisz tutaj oneline działa nam prawidłowo.
Mam wynik tylko dla tego jednego pliku i zaprezentowany w formacie oneline.
Jeśli chciałbyś wyszukać pośród Twoich zmian pośród commitów wszystkie które zawierają w swoim Message
czyli w opisie wiadomości do commitu jakieś dane słowo lub zbiór słów to mamy też taką opcję grep czyli git
log grep i powiedzmy podam opcję witaj i tu witaj.
Nic mi nie znalazło dlatego że jak pamiętasz w naszych commitach witaj podawałem z dużej litery i witaj.
Jak widzisz znalazło wszystkie wyniki.
Jeśli nie pamiętasz lub nie jest to istotne z jakiej litery wystarczy dać tę opcję bodajże i ignoruj
ignore case.
I w takiej sytuacja będzie z dużej litery czy podamy z małej litery jak widzisz znajduje mi wszystkie commity które
w swoim opisie w message zawierają słówko witaj tu jest witaj tu jest witaj.
I tu jest słówko witaj.
Możemy wyszukiwać nie tylko po treści wiadomości ale możemy też przeszukiwać całą treść commitu włącznie
z zawartością naszych plików.
Czyli w którym commicie jaka treść została dodana lub usunięta.
Sprawdźmy.
Git log i opcja tutaj s pozwoli mi wyszukać tekst np. znowu witaj.
Jak widzisz tylko tutaj w jednym tym znajduje się witaj.
Czyli tam mieliśmy dwa commity dlatego że dwa miały w nazwie witaj ale w jednym commicie tylko tworzyliśmy
pusty plik witaj.
Natomiast dopiero tutaj znajduje się w nim tekst witaj.
Możesz także zastosować tutaj opcję która pozwoli ci tutaj opcję g która pozwoli ci zamiast tutaj ciągu znaków zastosować wyrażenia regularne
czyli np. witaj w ten sposób.
Jest to szczególnie przydatne jeśli chcemy wyszukać jakąś treść wyszukać jakiś tekst który już nie istnieje
w projekcie którego nie ma w żadnym pliku i chcemy znaleźć znaleźć w którym ostatnim commicie on się jeszcze znajdował.
To ta opcja s lub g pozwoli nam wyszukać powiedzmy nieistotne
zmiany które zostały skasowane.
I tutaj mamy dwa commity i w obu tych commitach zostały dodane lub usunięte linie które zawierają
w środku ciąg znaków.
Nieistotne zmiany i mamy tu dwa commity moglibyśmy użyć polecenia git show i wyświetlić jakie zmiany zostały dokonane
w każdym z tych commitów.
Mamy też taką opcję jak start i start jak widzisz pokazuje nam w którym pliku została usunięta jedna linia.
Tutaj jedynka z minusem w którym pliku została dodana jedna linia.
Czyli na przykład możemy ten commit sobie podejrzeć zobaczysz że ta linia w nim została usunięta i jeszcze musi odzyskać treść odzyskać tą linie.
To będzie musiał wydobyć z tego commita jest jeszcze bardzo fajna opcja zamiast opcji stat mogę użyć
opcji patch i opcja patch dla każdego z naszych wyników wygeneruje tzw. patch czyli listę zmian listę
poleceń które będzie można którymi będzie można przywrócić usunięte zmiany w naszym pliku.
Czyli jak widzisz mamy informacje o commicie ale zaraz pod spodem jest takie polecenie jak widzisz diff
o którym będziemy rozmawiać.
I tu mamy porównanie dwóch plików w wersji wcześniejszej i wersji następnej.
Tutaj masz informację że plik został usunięty lub dodany tutaj jak widzisz dodany a tu usunięty a następnie pod spodem znajdują
się informacje.
Jakie zmiany w których liniach zostały dodane usunięte.
I dzięki takiemu podejściu widzisz możesz wyszukać różne informacje w historii zobaczyć kto modyfikował
kiedy.
Jakie zmiany wprowadził oraz w jakim czasie.
Czyli jak widzisz git log jest świetnym narzędziem które pozwala właśnie przeglądać historię wyłuskiwać
interesujące nas informacje jak zobaczysz w kolejnych lekcjach korzystając właśnie z takich informacji
jak tutaj diff patch i korzystając z git loga będziemy mogli posługiwać się naszą historią właśnie
do przywracania zmian do modyfikowania naszej historii oraz do wielu wielu innych fajnych rzeczy na
które pozwala git.
Ale to wszystko już w kolejnych lekcjach.
Do zobaczenia.