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!
Jak pamiętasz z poprzednich lekcji często korzystaliśmy z polecenia git push.
Do wysyłania naszych zmian z naszego lokalnego repozytorium na zdalne repozytorium. Git push pozwala
nie tylko wysyłać obiekty i commity ale jak zobaczysz w tej lekcji także inne obiekty np. referencje czyli
gałęzie albo etykiety powiedzmy git
pozwala także na kilka innych ciekawych rzeczy tutaj spróbuje wykonać git push na gałęzi master a on
się połączy ze zdalnym repozytorium.
I tu sprawdzisz że wszystko jest up to date czyli nie mamy żadnych zmian do wysłania.
Jeśli teraz wpisze git status to zobaczysz także informację.
Tutaj dodatkowo pojawił się napis your branch is up to date with origin master czyli dodatkowo sprawdza czy nie
mamy jakichś różnic jesteśmy do tyłu lub do przodu ze zmianami naszymi względem zmian zdalnych i to informacja
jest względem ostatniego sprawdzenia czyli ostatnie pobrane zmiany z origin master czyli z naszego konta
na git hubie tutaj są widoczne i są porównywane dodatkowo jak pamiętasz polecenie git Remote show Origin gdzie
Origin jest nazwą naszego repozytorium na git hubie tuaj jak widzisz adres kurs eduweb.pl
Mamy także informację że nasz gałąź nasz brancz master jest śledzony i polecenie git pull jest automatycznie
skonfigurowane by wszystkie zmiany wysyłać do gałęzi master i odpowiednio git push pobierać zmian z mastera i odpowiednio
git push jest skonfigurowany żeby wysyłać nam mastera.
Zobaczymy jednak co się stanie gdy stworz inną gałąź czyli jak będziesz git checkout minus b mógłby
zrobić odwrotnie czyli git branch.
Nazwa brancha wtedy checkout nazwa brancha jednak git checkout mogę zrobić tutaj jednym razem nazwiemy go na razie powiedzmy
test jestem na gałęzi test.
W tym momencie i teraz spróbujmy także zrobić git push tu jak widzisz mam informację że ta gałąź nie jest skonfigurowana
do łączenia się z jakimś danym branchem.
Mamy kilka możliwości mogę to tak jak mówiłem podaję skonfigurować git push set up stream Origin test
i takie polecenie wykonujemy gdy chcemy do już istniejącej gałęzi dodać właśnie gałąź z daną taką właśnie
konfigurację tak by wykonanie polecenia git push nastepnym razem już nie wymagało żadnych parametrów
po prostu wysyłało do tej gałęzi tutaj pokaże jeszcze tobie.
Nim to zrobimy jak wykorzystać tutaj właśnie git push bezpośrednio bez konfiguracji czyli poleceń git
push.
Po pierwsze potrzebuję informacji z którym serwerem z którym danym repozytorium chcemy się połączyć
czyli u nas będzie to nasz git hub czyli Origin bo pod taką nazwą się znajduje w konfiguracji i teraz po nazwie zdalnego
repozytorium.
Podajemy dwie rzeczy podajemy nazwę lokalnego obiektu który może być dowolny rev spec jak pamiętasz może to być
to nazwa commita hash commita nazwa brancha może być to head tu wpisze test bo to jest aktualny ten branch
ta gałąź na której jestem tutaj także jest head więc równie dobrze m,ógłbym tu wpisać head podaje dwukropek
i po dwukropku podaje nazwę zdalną brancha i w ten sposób ja wysyłam ten obiekt na którym jestem czyli
commit na który teraz wskazuje gałąź test do gałęzi test zdalnej czyli tam powinien się pojawić aktualny
commit na którym jestem właśnie w tej gałęzi sprawdźmy przełączyć tu i teraz do git huba przejdziemy
do zakładki branch jak widzisz mamy tutaj dwa branche mamy deafult branch master i branches
test tutaj pojawił się branch test stworzony niby dwa dni temu ale tu coś jest nie tak z zegarkiem OK.
Czyli tak mamy tutaj.
Wysłany na serwer gałąź test test jak widzisz tutaj nie wysyłał żadnych obiektów dlatego że wszystkie commity znajdują
się już na serwerze czyli wystarczyło tylko wysłać informacje o nowej gałęzi czyli jak widzisz w ten sposób
mogę dowolny obiekt wysłać.
Oczywiście tak jak powiedziałem przed chwilą tutaj może być dowolna referencje do dowolnego commita.
Ten commit ustawiamy jako początek tego brancha tutaj którego podajemy po dwukropku czyli test czyli takie
polecenie powinno znaleźć tam ten sam efekt.
Widzisz everything is up to date i teraz jeśli chcemy ustawić automatyczne śledzenie tego brancha to mogę wykonać
to polecenie git push set upstream origin test
mogę także zrobić jeszcze krócej czyli git push u to jest skrót do upstream origin test jeśli wykonam
to polecenie.
Tu będzie dokładnie to samo.
Everything is up to date nic nie trzeba było wysyłać ale zwróć uwagę dodatkowo mam informację teraz że nasza
lokalna gałąź test jest ustawiona by śledzić zdalną gałąź test z serwera origin oraz jak przyjrzymy się
konfiguracji git remote show origin.
Tutaj powinna nam się pojawić informacja jak widzisz śledzone gałęzie master i test i to jest odpowiednio także że test mergeuje
do remote test i test pushuje do test.
Oczywiście jeśli przyjrzymy się git config
to tutaj informacje znajdą się po prostu w naszym pliku config.
Czyli jak widzisz branch nazwa brancha mamy pod remote i wskazujemy z jakim zasobem zdalnym ten branch ma być
spięty ma być śledzony i mam informacje tutaj merge i fetch.
Czyli możemy ustawić sobie gdzie do jakiej gałęzi ma być.
Mają być wysyłane czyli mergeowane zmiany z naszej lokalnej gałęzi gdy wysyłamy zmiany do danej gałęzi
lub gdy pobieramy jakąś daną gałąź jest kopia takiej gałęzi przechowywana u nas w lokalnych plikach
mianowicie tutaj jeśli zrobimy sobie ls git to jak pamiętasz mieliśmy coś takiego jak refs w refs znajdowały się właśnie
wszystkie referencje m.in. nasze gałęzie heads nasze etykiety tags tutaj pojawiły się takżen refs remotes.
Pod refs remotes mam tutaj origin czyli nasz git hub origin.
Jak widzisz pojawiła się zarówno gałąź master jak i test i teraz spojrzymy na ten plik test nie po tym ls
tylko cat.
To jak widzisz jest to jakiś hash commita czyli po prostu tutaj zarówno przechowywane są w tym katalogu
git referencje do obiektów lokalnych czyli jak widziałeś heads do wszystkich naszych wskaźników do mastera
do wszystkich gałęzi przechowywany jest head oraz w katalogu remote.
Przechowywany jest tutaj.
Referencje które odpowiadają właśnie referencjom zdalnym w ten sposób git może błyskawicznie np. gdy wpisuje
git status to sprawdzić czy faktycznie nasza gałąź jest w tym samym miejscu co zdalna gałąź wystarczy że porówna po prostu sobie
te dwa pliki.
Jeśli w tej gałęzi stworzymy jakieś zmiany na przykład mamy ten plik test który stworzyłem w poprzednich
lekcjach czyli usuniemy sobie plik test txt git status git.
Commit spróbujemy w ten sposób usuwamy plik test
status.
Tutaj już nic nie ma i jak widzisz w tym momencie pokazuje nam że nasza gałąź jest o jeden commit do przodu
przed daną gałęzią origin test podpowiada także powinien wykorzystać git push aby opublikować nasze commity ja
to teraz zrobię git push to jak widzisz mamy już ustawione że ma być ten branch zsynchronizowany ze zdalnym
branchem.
Dzięki temu do git push ja już nie muszę podawać dodatkowych parametrów nie muszę pokazywać mu w które
miejsce ma wykonać te zmiany on już z konfiguracji wie że lokalna gałąź test ma być wypychana do zdalnej
gałęzi test ponieważ tak to skonfigurowaliśmy.
Sprawdźmy teraz na stronie tutaj git huba.
Tutaj widzimy informację że niedawno wypchnięty branch test ponad minutę mniej niż minutę temu mam tutaj dwa
gałęzie mamy gałąź test i mogę sobie porównać przełączając pomiędzy master i test mogę porównać sobie
tutaj pliki jak widzisz tutaj pliku tekst txt już nie ma tutaj jeszcze jest bardziej zaawansowana możliwość porównywania
ale do tego wrócimy w kolejnych lekcjach.
Czyli tutaj mamy nową gałąź.
Tak wyglądało tworzenie nowych gałęzi wysyłanie wysyłanie zmian widziałeś jak ustawiać śledzenie także
możemy śledzenie np. ustawić w ten sposób git branch.
U origin i powiedzmy zmienimy na master
i widzisz możesz bez wysyłania żadnych zmian także zmienić śledzenie.
Czyli nie musisz wykonywać push.
Poleceniem git branch tutaj u czyli set upstream skrót origin master pozwala przestawić to i teraz git status.
To nasz ponownie jest jeden do przodu ponieważ commita nie ma na masterze.
Ja tutaj nie będę tego commitował przestawię z powrotem tak jak było czyli origin test teraz będziemy mieli wszystko up to date.
Dokładnie i chciałam tak żebyś wiedział jak usuwać gałęzie jak pamiętasz powiedzeniem git branch minus
d mogłem usunąć lokalną gałąź ale usunięcie lokalnej gałęzi nie usuwa gałęzi zdalnej aby usunąć gałąź
zdalną musimy wypchnąć puste referencje do zdalenej gałęzi czyli po prostu git push origin.
I tutaj podawaliśmy skąd wysyłamy np. head do test.
Jeśli nie podam tutaj żadnej wartości.
W ten sposób
wypychamy pustą referencje do zdalnego brancha i wypychanie takiej pustej referencji sprawia że ta gałąź zostaje usunięta.
Ja mogę ponownie spróbować git push
to nam ponownie wypchnie naszą gałąź tak żeby tobie łatwiej było zapamiętać możesz po prostu w ten sposób to jest sam dwukropek
jest troszkę mylące jeśli nie pamiętamy że tutaj po prostu podajemy pustą nieistniejącą wartość.
Mamy też inną opcję możemy zrobić git push
delete origin master lub origin test mastera nie polecam usuwać.
Tak czyli jak widzisz tu łatwiejszy do zapamiętania jest myślnik myślnik delete i to usuwa zdalną gałąź zwróć uwagę że lokalna
gałąź cały czas istnieje.
Jedyne co zrobiliśmy to teraz jak wejdę w branches mamy tylko branch master usunęliśmy zdalny branch i tutaj jakby pokazać
jeszcze jedną rzecz ja ten branch z powrotem wypchnę.
Czyli git push tutaj trzeba będzie jeszcze raz a nie zadziałało.
Ok sprawdźmy tutaj jeszcze raz jest branch test ok i tutaj będzie jeden commit różnicy jeśli zrobię git.
checkout.
Master git diff albo git log test.
Tutaj ten właśnie nasz commit różnicy czyli usuwam plik test.
Tym różnią się te dwie gałęzie teraz jeśli te dwie gałęzie nam się rozjadą lub inaczej rozgałęzią
czyli inny commit powiedzmy.
Echo test
to test txt.
Mam tu jakąś informację w środku i w tym gałęzi w tej gałęzi zamiast go usunąć scommitujemy go ja mogę się zająć
treścią czyli spróbujmy zrobić git add test.
Git commit testowa treść do pliku test ok.
Teraz porównam jeszcze raz obie gałęzie tutaj w ten sposób zrobimy test.
W ten sposób czyli tutaj jak widzisz dwa różne commity każdy się on różni i spróbujmy teraz spuszować zawartość
gałęzi master do gałęzi.
Test jak pamiętasz git push pozwala nam wybrać tutaj gdzie czyli origin na git huba i wybrać branch.
Czyli mogę będąc na masterze lub właściwie będąc na dowolnej innej gałęzi mogę taką dowolną gałąź lub dowolną
referencje np. naszego mastera spróbować wypchnąć tutaj na dowolny inny z zdalny branch spróbujmy teraz
to co mamy w teście nadpisać to co mamy w masterze.
Jeśli spróbuję to zrobić a te zmiany są właśnie rozgałęzione.
Każde z nich nie są kompatybilne.
Nie można ich połączyć łatwo zmergeować no to mam tutaj właśnie rejected.
Czyli serwer zdalny odrzucił taką zmianę nie pozwala nam cofnąć nie pozwala nam robić zmian w pliku
które został usunięty.
Jeśli jednak zajdzie taka potrzeba okaże się że coś scommitowałeś źle chciałbyś cofnąć jakieś zmiany lub modyfikować
lokalną historię.
Możesz chociaż nie jest to zalecane zrobić tzw. push force force lub w skrócie po prostu f wymusi
taką zmianę tutaj jednak musisz uważać bo jeśli te zmiany które wysłałeś wcześniej już ktoś pobrał wprowadził jakieś
swoje zmiany.
Na tych zmianach a ty teraz te zmiany jakby skasujesz cofniesz to automatycznie bierz pod uwagę że psujesz
pracę wszystkim osobom które już te zmiany pobrały i był problem.
Znowu pobrać zmiany zrobił się straszny bałagan bym musiał wszystkie swoje zmiany jeszcze raz zaaplikować.
Na twojej zmienionej historii więc bardzo odradzam używanie tego polecenia force.
Jednak chciałbym żebyś wiedział że takie polecenie istnieje no gdyż czasem zdarzy się że na repozytorium
pojawią się nie te commity które chciałeś nie w tej kolejności i trzeba będzie posprzątać.
Pamiętaj jednak że przed takim f lub natychmiast jak tylko zrobisz taki właśnie force push żeby poinformować wszystkie osoby
że taka tutaj gałąź została zmieniona i po prostu mogą powstać pewne problemy przy pobieraniu.
Tutaj warto wspomnieć że git push origin powiedzmy pozwala Tobie jednocześnie wypchnąć do kilku gałęzi
master test mogę od razu spróbować na przykład na dwie gałęzie jednocześnie wysłać jako że już był ten konflikt
to na teście znowu się coś nie udało.
Jeśli nie jesteś pewien czy taki na przykład push się uda czy nie będzie jakiś tam problemów zawsze możesz do tych poleceń
dodać opcję dry run.
I takie coś wykona wszystkie faktyczne operacje ale bez zmieniania czegokolwiek na danym serwerze.
Jeśli się boisz trzeba wiedzieć że nie ma konfliktów nie ma problemów.
Nie chcesz robić bałaganu.
Możesz dodać zawsze taką try run czyli spróbuj na sucho i tutaj git.
Spróbuje zrobić wszystko bez faktycznego wprowadzenia zmian.
To są najważniejsze polecenia najważniejsze parametry polecenia git push pamiętaj po prostu że git push pozwala wszystko.
Twoje zmiany twoją prace twoje referencje gałęzie wysłać na zdalny serwer.
Niektóre będą lokalne zmiany i gałęzie.
Jeśli chcesz żeby na przykład tagi czyli etykiety może zrobić git push i podać nazwę taga np. po prostu nazwa taga.
Jeśli chcesz przejść wszystkie gałęzie masz opcję all jest jednak odradzane robi się straszny bałagan zrobić
gdzieś na serwerze tak że jest opcja Tax która wyśle wszystkie gałęzie na serwer i ponownie jest odradzany
chyba że tych gałęzi jest kilka i na pewno wiesz co robisz.
Ok to tyle jeśli chodzi o polecenie git push w kolejnych lekcjach zajmę się drugą stroną tej komunikacji z serwerem czyli
zajmę się poleceniem git pull który pozwoli nam pobrać zmiany które wysłaliśmy na serwer.
Do zobaczenia.