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 działają polecenia git pull git push git fetch.
Mam nadzieję że pamiętasz także jak korzystaliśmy z powiedzenia git rebase które pozwalało nam zmienić
kolejność naszych commitów zaaplikował je w innej kolejności niż zostały oryginalnie stworzone dlatego
że w tej lekcji pokażę ci jak wykorzystać nowe polecenie a właściwie polecenia git pull z nowym parametrem
z parametrem rebase który pozwoli nam pobrać zmiany ale pobrać w zupełnie innej kolejności niż zrobił
to sam git pull aby zasymulować pracę dwóch różnych osób mam otworzony jeden edytor ustawiony na katalog
pierwsza strona mam drugi edytor ustawiony na katalog strona współautor i teraz oba te katalogi są repozytoriami
git.
Każdy z nich zawiera dokładnie tę samą wersję ale każdy z nich ma ustawionego innego autora tutaj jest
nasz eduweb git a drugi katalog mamy strona współautor i tutaj autorem jest git collaborator tylko przykładowy
adres tymczasowy i zmiany są także wysłane na nasze zdalne repozytorium.
Także oboje git collaborator eduweb git oboje będą mogli wymieniać się zmianami przesyłając je poprzez tutaj nasze
repozytorium na githubie.
Powiedzmy więc że przejdę do pierwszego edytora tutaj mamy taką sytuację mamy praca równoległa kończy
się na cherry pick i odpowiednio do naszego collaboratora mamy tak samo tutaj kończy się na cherry pick i powiedzmy że nasz collaborator
utworzy zmiany jednak nie chcemy tych zmian dodawać w gałęzi master.
Ja chciałbym utworzyć specjalny branch specjalną gałąź na potrzeby tej pracy czyli np. zrobię sobie git
checkout branch współpraca
współpraca i zrobimy jeszcze track origin master.
Czyli chciałbym stworzyć nową gałąź tylko na potrzeby tego jednego zadania.
Ale żeby ta gałąź śledziła origin master i też w tej gałęzi podam tutaj dodatkowe zmiany.
Powiedzmy tutaj dopisze li merge ok i scommitujemy git commit dodaj zmiany i scommituj jako merge.
Dodam jeszcze jakąś zmianę
zostawmy tutaj i powiedzmy że w tym czasie zmianę także wprowadzi nasz główny autor i zobaczymy jeszcze
git log.
W ten sposób tu byliśmy daliśmy merge git status jesteśmy jeden commit do przodu i powiedzmy że w tym czasie
gdy my pracowaliśmy nad tą zmianą.
Drugi autor także wprowadzi jakieś zmiany ale może w innym miejscu abyśmy nie mieli na razie żadnych
konfliktów.
Czyli tutaj dodamy powiedzmy ignorowanie
zmian.
Ok to sobie skopiuje tą nazwę zapiszemy i teraz w tym miejscu pierwsza strona zrobimy tak że git commit
ignorowanie zmian i powiedzmy że ten główny autor od razu te zmiany wysłał czyli zrobił git push origin
master i wyśle te zmiany na mastera ok.
Udało się i teraz ten collaborator.
Pracujący na gałęzi współpraca która śledzi gałąź master zobaczmy git status mamy jeden do przodu.
Ale zrobimy git fetch jeśli pobierzemy najnowsze zmiany z gita i teraz jeszcze zrobimy git status to mamy
komunikat że twoja gałąź i origin master tutaj się rozdwoiły.
Czyli każda poszła w inną stronę czyli ze wspólnego rodzica każda dodała równoległą zmianę i teraz mógłbym
oczywiście zmerge'ować moje zmiany do mastera nasz collaborator.
Oryginalny autor pobrałby te zmiany i możesz pracować dalej.
Problem pojawia się gdy moja zmiana nie jest gotowa.
Nie chcę jej jeszcze merge'ować do mastera.
Chciałbym kontynuować tą pracę powiedzmy jako ten nasz współautor.
Dodam tutaj kolejne zmiany.
Jak widzisz tutaj zmian jeszcze nie pobrałem z gałęzi master.
Jak widzisz tutaj jest stara jeszcze wersja.
Ja tu dopiszę kolejną operację powiedzmy klon ok zapisze jako współautor.
Dodam kolejny commit
clone.
I teraz gdy robię git status mamy znowu informację że gałęzie się tutaj rozdwoiły aczkolwiek mam dodatkowe
informacje że mamy dwa i jeden commit każdy odpowiednio.
Czyli ja mam dwa commity do przodu a master ma jeden commit do przodu i teraz gdybym ja zmerge'ował tą pracę
która nie jest powiedzmy skończona lub po prostu skończył pracę i zmerge'ował to teraz ten drugi współautor miałby
nasz specjalny commit typu merge.
Ja spróbuję to tutaj zrobić git merge origin master i powstaje tutaj taki brzydki merge komunikat że mój branch a właściwie
origin master wrzucam do mojej gałęzi i w ten sposób
powstaje taka brzydka historia że mam oryginalne moje commity tu taki merge i tu znowu moje commity
tak czy co chwilę informacja że kiedy do tego te nowe zmiany pobiera spróbuję zrobić sobie troszeczkę lepiej
zrobię tutaj git reset hard head o jeden do tyłu się cofniemy zróbmy jeszcze raz oneline mamy klon i
teraz co możemy zrobić dzięki poleceniu git pull rebase ja mogę zrobić zmianę kolejności tych wszystkich
commitów.
Czyli zamiast dokładać mastera na samym końcu ja mogę zdjąć moje commity czyli klon merge cofnąć się
do polecenia cherry pick tutaj dodać wszystkie zmiany stworzone przez pozostałe osoby czyli pobrać z naszego
naszej gałęzi i zaaplikować jeszcze raz moje zmiany tak jakby one zostały dodane na końcu.
Czyli jak widzisz git rebase pozwoli nam zmienić kolejność wykonywania operacji tak jakbyśmy wszyscy pracowali.
Jeden po drugim.
Naprawdę każdy z nas pracuje równo równolegle a na samym końcu dopiero przestawiamy zmiany.
Spróbujmy to zrobić.
Zwróć uwagę jak wygląda teraz nasza historia.
Git pull rebase origin master.
Jak widzisz tutaj mam informację że po pierwsze pull pobrał nasze zmiany do gałęzi do plików fetch head następnie
zwróć uwagę rewinding head to replay your work on top of it.
To znaczy że cofamy head do wspólnego miejsca z masterem aplikujemy wszystkie zmiany które pojawiły się w naszej
gałęzi śledzącej czyli właśnie master a następnie replay your work czyli wszystkie commity są tam jeszcze
raz aplikowane.
Tak by one zostały dodane po tych commitach które zrobił nasz oryginalny collabolator.
W ten sposób jeśli spojrzymy naszą historię mam tutaj czystą historię mamy cherry pick ignorowanie zmiany jak
widzisz z mastera merge i clone zwróć uwagę że merge i klon mają tutaj tym razem zupełnie inne hashe.
Dlatego że polecenie rebase tak jak pamiętasz musi utworzyć nowe commity dlatego że mają one nowego
rodzica.
Jeśli zmienimy rodzica commita musi zmienić się także jego hash czyli nasze commity są tutaj jakby kopiowane jeszcze
raz aplikowane jeszcze raz z nowym hashem ale dzięki temu kolejność zmian tutaj jest idealnie zachowana
i w ten sposób jeśli ja postanowię postawię spushować taką gałąź a najlepiej.
Git checkout.
Master przełączyć na mastera tu zrobić git pull.
Tak na masterze nie robimy rebase'a a git merge współpraca.
Tutaj wszystko poszło gładko i mogę tutaj zrobić git push origin master ok i teraz nasz collaborator nasz
oryginalny autor pierwsza strona git pull pobierając zmianę
zobaczy elegancką historię i będzie wyglądało tak jakby nasz współautor collaborator czekał aż my skończymy
zmiany i dopiero wtedy tworzył jego commity.
Tak naprawdę nasz collaborator równolegle z nami pracował nad tymi swoimi zmianami.
My w tym czasie robiliśmy tą zmianę ale przed spushowaniem.
Dzięki połączeniu git pull rebase zamienił kolejność czyli jego zmiany zostały odłożone na bok zostały
zaaplikowane zmiany tego tutaj collaboratora głównego a następnie te jego zmiany zostały jeszcze raz dodane na końcu.
Oczywiście gdyby zostały zmienione te same linie pojawiłby się w tym czasie konflikt który trzeba byłoby
rozwiązać.
Jedyną różnicą będzie rozwiązywanie konfliktu przy użyciu nie polecenia git merge continue ale git rebase
continue dlatego że polecenie git pull rebase zamiast zmerge'owania naszych zmian pobranych z danego serwera
z repozytorium zrebase'uje nasze zmiany czy rozwiązywanie konfliktu będzie odbywało się dokładnie w taki
sam sposób jak odbywało się przy użyciu polecenia git rebase minus i czyli interaktywnego rebase'a.
Musisz też pamiętać żeby nigdy nie rebase'ować zmian które już zostały wysłane dlatego że jeśli zmienisz
pliki które już inne osoby pobrały to zmusisz je do ponownego pobrania tych samych plików i skasowania
wszystkich zmian które utworzyły.
Jest to bardzo niewygodne bardzo nieprzyjemne dlatego pamiętaj żeby nic nie rebase'ować dalej niż tutaj.
Miejsce w którym jest twój origin master lub inna gałąź z której śledzisz.
Jeśli zrobisz rebase tutaj wcześniej jeszcze albo zrobisz pulla odpowiednio wcześnie no to jest ryzyko że twoje zmiany
kolejności będziesz próbował wysłać na serwer.
Tak mógłbyś to zrobić to z poleceniem git push minus f czyli force aczkolwiek pamiętaj że zmusisz to wszystkich
innych do zmiany także swojej historii jeśli wykona jakąś pracę tą prace może będą musieli jeszcze
raz zaaplikować.
Będzie to dużo pracy i dużo nieprzyjemności dla pozostałych.
Wystarczy po prostu że pull rebase robisz na swoich lokalnych gałęziach a na gałęziach zdalnych robisz już
push i pull.
Normalnie czyli rebase'ujemy nasze lokalne zmiany względem zmian serwera ale gdy już wypchniemy jakieś
zmiany to już ich nie rebase'ujemy.
Tak i to jest prosta zasada która pozwoli ci uniknąć wielu nieprzyjemności a więc już nie git pull rebase.
Jeśli pracujesz tylko na lokalnym branchu rebase'ujesz jeszcze lokalnego brancha pozwala ci na końcu pousuwać
bardzo ładną elegancką historię bez wrzucania tutaj jakichś informacji o merge'ach zmianach i poprawkach.
Pamiętaj też że zawsze na swoich commitach których jeszcze nie wysłałeś ani których nie pobierałeś zawsze
możesz zrobić po prostu git.
Rebase interactive i własnoręcznie zmienić kolejność nazwy commitów możesz ich połączyć podzielić.
Wszystko co robiliśmy w lekcji pod tytułem git rebase to tyle jeśli chodzi o pobieranie i prostą pracę
równoległą w kolejnych lekcjach zobaczysz nieco bardziej zaawansowane techniki pracy zespołowej.
Do zobaczenia.