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!
Wiesz już jak tworzysz commity.
Jak zapisywać ich historię zmian w twoim projekcie a także wiesz jak dzięki poleceniu git log możesz
łatwo przeglądać sortować filtrować tą historię na różne sposoby.
Jednak czasem przydaje się dowiedzieć co dokładnie zostało zmienione to znaczy podejrzeć w których plikach
które linie zostały zmienione które dodane usunięte i jak widziałeś poprzedniej lekcji wystarczy do
płacenia git log dodać polecenie minus p które oznacza patch gdzie patch jest tzw. łatką czyli różnica pomiędzy
dwoma plikami w tej lekcji pokażę ci narzędzie git diff które właśnie służy do tworzenia takich łatek czyli
wyświetlania ci różnic pomiędzy dwoma plikami a także pozwala pokazać różnice między całymi commitami
czyli możesz zobaczyć w bardzo łatwy sposób jakie pliki zostały zmienione w których miejscach które linie
zostały zmienione pomiędzy dwoma commitami możesz także dzięki poleceniu git diff sprawdzić jakie są
zmienione pliki w tym roboczym katalogu lub porównać zmiany w plikach z plikami które masz zapisane
w indeksie czyli w tym miejscu w którym przygotowujesz pliki dodajesz pliki do scommitowania.
Ok spróbujmy git diff jeśli uruchomię go w tym momencie w katalogu nie wyświetla nic.
Dlatego jak zobaczysz git status nasz aktualny folder roboczy jest na równi z ostatnim commitem na
brunchu na gałęzi master czyli praktycznie nie ma tutaj żadnych zmian jesteśmy dokładnie na tym samym etapie
jak ostatni nasz commit spróbujmy więc dokonać jakichś zmian.
Przejdę do edytora i tutaj mam nasz plik witaj txt.
Dodam do niego jeszcze jedną linię
zapisze plik i ponownie wykonam polecenie git.
Status mamy tutaj jeden plik zmodyfikowany wykonam polecenie git diff.
Jak widzisz mam tutaj bardzo prostą łatkę czyli specjalny format który służy do właśnie wyświetlania
lub zapamiętywania różnicy między dwoma plikami.
Jak widzisz w pierwszej linii masz informacje jak i jakie pliki są porównywane jest tutaj porównywany dokładnie
ten sam plik witaj w dwóch wersjach A i B czyli w wersji zapamiętanej i w wersji którą aktualnie mamy
w katalogu tu są meta dane pliku i poniżej.
Jak widzisz mamy tutaj trzy minusy i trzy plusy i teraz dla każdego pliku masz jakby oznaczenie jakim
symbolem.
Tutaj będzie oznaczona każda linia dla danego pliku.
Dwa minusy można przyjąć to jest usunięcie linii ale tak dokładniej rzecz biorąc dwa minusy to właśnie
ten minus na początku oznacza że jest to zmiana a właściwie stan w poprzednim pliku.
Jak widzisz miałem tutaj linię która zawierała witaj świecie.
Zaczyna się od myślnik od minusa i to jest linia z tego pliku natomiast tutaj poniżej są linie zaczynające
się od plusa i to są linie które są właśnie w tej samej pozycji w pliku tutaj b.
Jak widzisz zmieniła się pierwsza linia i druga linia.
Odjęta została jedna linia i dodana linia pierwsza i druga.
Dlaczego mam zmienione dwie linie skoro tak naprawdę mam tylko jedną.
Zwróć uwagę że gdy dopisywałem tutaj jeszcze jedną linię to musiałem tutaj wstawić Enter przejdź do nowej
linii.
To mi tak naprawdę zmieniło dwie linie zmieniłem linie.
Witaj świecie dodałem tutaj na końcu Enter.
Jak widzisz w pierwszym pliku masz informację że nie było znaku nowej linii na końcu pliku natomiast
w kolejnej tej wersji naszej aktualnej wersji plik został zmieniony.
Mamy tutaj nową linię dodaną w pierwszej linii.
Czyli tu był znak Enter więc ta linia się zmieniła.
Mamy naszą całą nową linię czyli niektóre zmieniliśmy.
I na końcu tym razem wstawiałem znak Enter.
Więc jak widzisz nie ma tu już informacji o tym że nie ma nowej linii na końcu pliku.
Jedna taka łatka czyli wynik polecenia git diff może oczywiście zawierać zmiany w wielu różnych plikach.
Spróbujmy tutaj przejść do edytora i zmienię jeszcze jeden plik.
Powiedzmy że w naszych notatkach.
W przeczytaj to napiszę.
Ważna informacja zapisze plik git status.
Jak widzisz mam teraz dwa pliki zmienione natomiast git diff.
Wyświetla mi teraz zmiany w obu plikach.
Zwróć uwagę że te dwie małpy oznaczają tzw. chunk czyli jedną pojedynczą zestaw jakby jeden pojedynczy
zestaw zmian.
I tutaj akurat w każdym pliku jest tylko jedna zmiana i gdyby te pliki były dłuższe i wprowadziłem kilku zmian
w różnych liniach w różnych miejscach to tutaj widziałbyś kilka takich właśnie sekcji.
Gdy w przypadku mamy w ramach jednej łatki po jednym chunku czyli po jednym fragmencie na każdy plik mamy
dwa pliki plik przeczytaj to txt i plik witaj txt.
Bardzo istotną rzeczą jest że my porównujemy jakby aktualny stan naszego katalogu z zapisaną ostatnią
zmianą.
To jest bardzo istotne bo teraz gdy zrobię git status i powiedzmy jeden z tych plików zachowam sobie
czyli git.
Add.
I powiedzmy witaj txt.
Więc jeden plik mam w naszym katalogu roboczym a drugi już jest śledzony jest w indeksie jest gotowy
do scommitowania.
I teraz gdy ponownie wykonam git diff to pamiętaj że zmiany wyświetlane są względem ostatnio zapisanej
wersji.
Teraz naszą ostatnią zapisaną wersją tak naprawdę nie jest w tym momencie ostatni commit tylko ostatnią
zapisaną wersją jest właśnie ta wersja którą mamy tutaj w naszym indeksie.
Jeśli chcesz porównać indeks z ostatnim commitem to tutaj git diff wymaga opcji cached.
Czyli porównaj zapisaną wersję z ostatnim naszym indeksem.
Możesz porównać nasz katalog roboczy.
Możesz porównać indeks i zawsze odwołuje się tutaj w tym przypadku do ostatniej wersji czyli odpowiednio
teraz git.
Diff bez żadnego parametru.
Wyświetlam tylko zmiany w naszych nie obserwowanych jeszcze nie dodanych katalogach czyli na przykład notatki.
Jeśli masz wiele wiele plików zmienionych i chciałbym zobaczyć różnice tylko w jednym pliku lub w jednym
katalogu to nic nie stoi na przeszkodzie żeby wybrać tylko daną ścieżkę git diff bez cached i mogę zrobić
np. notatki.
I tu zobaczymy wszystkie zmiany w całym katalogu notatki jest tu tylko jeden plik jest to plik przeczytaj to
i jeśli wybierę jakiś inny plik z katalogu notatki np. notatki notatka txt git diff nie zwraca żadnego wyniku
dlatego że po prostu nic się w tym pliku nie zmieniło.
Taki diff jest bardzo przydatnym narzędziem jeśli chodzi o porównywanie aktualnej wersji z poprzednią wersją
zapisaną.
Ale to nie jest jakby limit jego możliwości do git diff będę musiał przekazać wiele plików witaj i notatki wyświetli
mi tylko te pliki które się zmieniły.
Może też się zdarzyć że nie chcesz porównywać tutaj naszych plików np. witaj txt z ostatnią wersją
tego dokładnie pliku tylko chciałbyś np. porównać dwa różne pliki i zobaczyć czym one się różnią.
Mam tutaj witaj i powiedzmy chciałbym porównać go z notatki i notatka txt.
I takie coś nie zadziała dlatego że oba pliki jak widziałeś przed chwilą będą porównane z poprzednimi wersjami jeśli tutaj
natomiast dodam dodatkową flagę mianowicie no index.
Czyli nie sprawdzaj w naszej historii zmian tylko bezpośrednio porównaj te dwa pliki.
I widzisz mogę dwa zupełnie dowolne pliki sobie wybrać i zobaczyć właśnie czym one się różnią.
Tu są zupełnie różne pliki więc cała zawartość się zmieniła.
Jeśli te pliki miałyby podobne linie no ten algorytm git diff spróbowałby pokazać gdzie dokładnie znajdują się różnice.
Git diff właśnie nie tylko pozwala pracować na aktualnym katalogu i na ostatniej zmianie korzystając z git diff
możemy porównywać wcześniejsze zmiany na przykład spróbujmy zrobić git log.
Mamy tu historię naszych commitów i zapisując polecenie git diff.
Mogę na przykład porównać korzystając z hasha skróconego dwa dowolne commity w historii i tu jak widzisz
mam różnicę pomiędzy dwoma commitami mogę już troszkę inaczej.
Mogę też podać np. head i mamy tutaj po kolei wszystkie zmiany od tego pierwszego commita do head.
Mogę tak tutaj podać tylko ścieżkę chciałbym zobaczyć tylko zmianę witaj i tutaj witaj.
Jakby się nie zmieniło.
Spróbujmy zobaczyć notatki w notatkach została dodana notatka pomiędzy tymi dwoma commitami.
Dokładny zapis
ale ten sam efekt.
Możesz podać tutaj po prostu dwa commity.
Na końcu ścieżkę ale w tutaj ten sposób jest dokładniejszy zapis jest.
Dokładny mówimy że chce różnicę pomiędzy wszystko pomiędzy tymi dwoma commitami.
Widzisz mogę podać dokładnie commit.
Mogę też podać jego referencje wskaźnik czyli aktualny head na którym jesteśmy.
Mogę także sprawdzić tutaj np. porównać sobie z master i jest to aktualna gałąź.
Będzie to tak samo.
W tym momencie head bo wskaźnik head jest na wskaźniku na branchu na gałęzi master czyli jak widzisz git diff pozwala
na wiele wiele różnych opcji.
Dodatkowo oprócz pokazywania samych zmian w plikach mamy kilka takich możliwości powiedzmy statystycznych.
Mogę do git diff przekazać także opcję stat.
I tutaj widzisz mam tylko informację jakby coś się zmieniło.
Spróbujmy jeszcze git status przywrócić na chwilę
plik witaj sprawdźmy teraz jak wygląda nasz diff jak widzisz git diff z opcją stat nie pokazuje całej zawartości plików
tylko mam taką skróconą informację ile plików się zmieniło ile zostało linii dodanych ile linii usuniętych
w całym tym w tym diffie w tym patchu.
Mamy też opcję short stat
bez już wyliczania wszystkich plusów i minusów czyli bez tych dodanych zmienionych linii.
I jak zawsze tutaj jest wiele innych dodatkowych ciekawych opcji polecam uruchomić sobie jeszcze flagę
help i zobaczyć co tam jeszcze kryje diff.
Jeśli chodzi o wyświetlanie to są najważniejsze rzeczy ale git diff nie służy tylko do podglądanie dla nas
tych zmian.
Ten format też jak widzisz on nie jest najbardziej czytelny.
I to dlatego że on nie służy tylko do przeglądania przez użytkownika tych zmian chociaż do tego też
bardzo się przydaje ale pozwala on zmiany wysłać zapisać i później zmianę dołączyć do zapisanego pliku
czyli dając git diff.
I powiedzmy notatki.
Przeczytaj to mam taki tutaj patch czyli łatkę taką łatkę.
Ja pozwolę sobie zapisać do pliku łatka kropka.
Patch.
I tutaj nasz plik zmienię powiedzmy będzie tutaj ważna informacja ja go przywrócę z powrotem tak jak on wyglądał czyli straciłem
moje zmiany ale nie do końca dlatego że w pliku tutaj łatka kropka ptch te zmiany są zachowane i mogę
teraz łatwiej je otworzyć.
Wystarczy że wpisze tutaj git apply i podam ten plik
łatka patch i takie polecenie git apply aplikuje czyli jeszcze raz wykonuje te wszystkie zmiany które
zachowane są w pliku łatka patch w naszym projekcie czyli robi odwrotną rzecz jak diff diff odnajdywał
wszystkie różnice między plikami i pozwalał mi właśnie taki spis różnic zapisać do pliku.
łatka kropka patch.
Natomiast git apply działa odwrotnie pobiera sobie tę różnicę między plikami i jeszcze raz aplikuje
te różnice czy aplikuje listę zmian w plikach.
Jeśli teraz przejdę do edytora zwróć uwagę tutaj moje zmiany z powrotem wróciły mam z powrotem ważne informacje.
Czyli jak widzisz git diff pozwala nie tylko podejrzeć zmiany ale pozwala takie zmiany zapisać lub np. wysłać
komuś innemu i kiedyś takie zmiany były wysyłane mailem żeby np. druga osoba mogła sobie zaaplikować takie zmiany w projekcie
w kolejnych lekcjach zobaczysz jak nie robić tego ręcznie jak nie tworzyć plików
typu łatka patch tylko jak pracować na różnych gałęziach i właśnie jak przenosić wysyłać zmiany innym użytkownikom
dzięki czemu będzie można współpracować nim jeszcze jednak do tego przejdziemy pokażę ci jak pracować
z historią jak przywracać zmiany jak modyfikować historię nim jeszcze zaczniemy pracę w zespole no ale
o tym wszystkim już w kolejnych lekcjach.
Do zobaczenia.