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 korzystać z funkcji z poleceń gita zarówno do pracy lokalnej
na własnym komputerze do pracy na wielu gałęziach oraz do pracy zdalnej do współpracy z innymi osobami
korzystając z serwera zdalnego repozytorium np. takiego jak git hub w tej sekcji kursu zajmiemy się
już nie tyle pojedynczymi poleceniami co dobrymi praktykami i technikami pracy z gitem w tej lekcji
pokażę ci jak wygląda praca scentralizowana gdy mamy jedno repozytorium centralne i wszyscy współpracownicy
pracują właśnie na takim jednym repozytorium tutaj mam utworzony terminal naszego współautora na gałęzi
głównej master zawsze pracę warto zacząć od sprawdzenia statusu git status tutaj mamy repozytorium up to date
czyli nie mamy żadnych lokalnych zmian working tree clean czyli nie mam tu nic do scommitowania.
Nie mamy żadnych zmian.
Po drugie warto sprawdzić jak wygląda sytuacja na naszym zdalnym serwerze czyli git pull.
W tym przypadku mam już skonfigurowane na origin master czyli ze zdalnej gałęzi origin master naszego
serwera github pobieramy zmianę i nie ma tam nic nowego.
Tak więc jesteśmy na bieżąco nie mamy ani żadnych zmian nieskomitowanych ani także nie mamy żadnych zmian zdalnych
na danym serwerze które musieliśmy pobrać.
W takiej sytuacji moglibyśmy już rozpocząć prace aczkolwiek pamiętaj żeby nie pracować na gałęzi master.
Jeśli pracujesz z innymi osobami gałąź master jest takim waszym wspólnym miejscem gdzie chcecie mieć już
końcową gotową pracę sprawdzoną.
Więc nie pracujemy na gałęzi master pobieramy zmiany od innych i integrujemy nasze gotowe
zmiany do bieżącej pracy pracy nie ukończonej niesprawdzonej.
Utworzymy tutaj dodatkową gałąź czyli git checkout minus b.
Gałąź dev lub development.
Niektórzy wolą używać.
I jest to gałąź deweloperska jest to gałąź taka na której mamy także wspólny kod.
Tutaj także wymieniamy się najnowszą wersją kodu aczkolwiek na gałęzi dev mamy wersje jeszcze niesprawdzone
i jeszcze nieskończone.
Tutaj wymieniamy się pracą która jest jakby do sprawdzenia która jest najnowszym etapem projektu.
Ale to jeszcze nie jest gotowa praca do opublikowania.
Dopiero gdy tutaj sprawdzimy jakąś wersję naszego projektu jest ona gotowa sprawdzona dodajemy wtedy
git tag oznaczamy etykietą że w tym miejscu wszystko jest sprawdzone i taką sprawdzoną oznaczoną wersję możemy
dopiero zmergeować do mastera.
Tak więc na tej drugiej gałęzi na gałęzi dev także nie wykonujemy jeszcze naszej pracy gdy chcemy
wykonać jakąś jedną jednostkę pracę tworzymy tak zwaną gałąź tematyczną i powiedzmy że w naszym systemie
zgłoszeń przyszło zgłoszenie że należy w naszym kodzie poprawić błąd że brakuje powiedzmy tutaj jednej
pozycji na naszej stronie w spisie treści trzeba też jej pozycję czyli tak tworzę nową gałąź tutaj wyciągamy ją z
deva czyli git checkout.
Zróbmy tutaj sobie branch i teraz powiedzmy że zgłoszenie ma dajmy na to numer sześć trzy dziewięć.
Tutaj podaję numer zgłoszenia 6 3 9 i zgłoszenie powiedzmy że dotyczy dopisania pozycji merge conflict
więc nazywamy tutaj taką gałąź odpowiednio tak jak zgłoszenie w skrócie powiedzmy merge config.
I tutaj ta nazwa służy nie tylko nam ale także w razie czego naszym współpracownikom gdybyśmy chcieli kiedyś
taki branch wepchnąć żeby łatwo zidentyfikować do czego czego dotyczy jaki jest temat tej jednostki pracy którą chcemy wykonać
jest to zgłoszenie 6.3.9 w naszym systemie.
Można dzięki temu bardzo łatwo odnaleźć czego dokładnie dotyczy ten kod ale także mamy tutaj taką skróconą
nazwę która nam jako autorom czy naszym współpracownikom jeśli chcieliśmy taką gałąź wypchnąć na serwer taka informacja
powie czego to dotyczy gdybym poleceniem git branch dostajemy listę wszystkich branchy i zobaczymy od razu który
mniej więcej czego dotyczył i jakiego właśnie tematu.
I takie podejście to nazywa się branch.
Topic czyli branch tematyczny czyli gałąź która służy do pracy nad jedną konkretną rzeczą nad jedną
jednostką pracy.
I teraz tutaj przyłączyłem się do tego na tą nową gałąź.
Takie podejście pozwala mi swobodnie wprowadzać tutaj zmiany czyli mogę np. do edytora przejść dodać nową pozycję
powiedzmy że zgłoszenie dotyczyło właśnie dopisania tutaj pozycji w naszym spisie treści więc dodam sobie tutaj
merge conflict conflict ok git status jeden plik i commit dodamy go i od razu dodamy message i message
będzie dokładnie tutaj taki sam powiedzmy że chodziło o merge conflict taką nazwę damy i teraz nasza gałąź
zrobimy sobie git log jest o jeden do przodu przed masterem devem i pozostałymi branchami.
Czyli mam tutaj jakieś zmiany wprowadzone.
Ja z takich branchy topicowych lub branchy tematycznych pozwala nam swobodnie kontynuować pracę nad tą gałęzią.
Zmiany w tych plikach dodawać nowe commity i nie martwić się zupełnie o to co się dzieje dookoła nie martwimy
się innymi branchami innymi gałęziami możemy w pełni skupić się na naszej pracy i dopiero gdy skończymy
taką gałąź możemy merge'ować.
Teraz pytanie w którym miejscu mógłbym taką gałąź wypchnąć zrobić git push i umieścił na serwerze.
Ale jeśli nie potrzebuje informacji od pozostałych członków zespołu nie potrzebuje tutaj współpracować
z kimś.
Ta zmiana jest skończona wystarczy teraz zintegrować i teraz żeby ta zmiana była na bieżąco.
Warto tutaj uzupełnić o najnowsze zmiany z innych gałęzi.
Czyli możemy robić git pull origin dev i z gałęzi dev z której pobraliśmy z której wyciągnęliśmy tę
gałąź z powrotem do tej gałęzi zrobiłem merge.
Sprawdźmy i to tak się udało że nie mamy tam żadnych zmian w tym czasie nikt nie wprowadzał zmian jeśli
tam pojawiły się zmiany.
Tutaj pojawiłby się merge.
Mamy też opcje git pull rebase o której dowiedziałes się w poprzednich lekcjach które pozwalałby te nasze zmiany
odłożyć na bok zaaplikować wszystkie zmiany z gałęzi dev i jeszcze raz zaaplikować nasze zmiany i także
możliwe rozwiązać jakieś konflikty.
Ale tym razem nasza historia byłaby bezpośrednią kontynuacją tego co zdarzyło się na devie byliśmy pewni
że nasza gałąź jest na pewno zintegrowana z gałęzią dev czyli wszystkie zmiany współpracowników są już uwzględnione
to możemy z powrotem przejść do gałęzi dev czekam tu dev do tej gałęzi domergeujemy naszą gałąź tematyczną
czyli zobacz nie przechodzę jeszcze do mastera.
Tutaj mamy możliwość popełniania błędów tutaj mamy możliwość jeszcze naprawienia na masterze będziemy
chcieli już umieszczać tylko pewną bezpieczną wersję całego naszego projektu czyli gałąź developerska
to jest ta na której podzielimy się naszą zmianą z innymi.
I tutaj robimy sobie git merge i
dodamy nasze zmiany czyli 6 3 9 merge conflict.
Tutaj był fast forward merge i nie zawsze takie coś chcemy.
Czasem chcemy dokładnie powiedzieć co my łączymy.
Więc jeśli była jakaś mała zmiana i tutaj jest git log być dokładnie wynikało.
O co nam chodzi.
No to jest OK.
Jeśli chciałbyś każdą taką integrację dokładnie opisać to tutaj wycofam się git reset hard head o
jeden zrobię jeszcze raz merge ale z opcją no fast forward jeśli wykonamy to polecenie w ten sposób.
Jak widzisz on pyta się mnie o message dla naszego nowego commita.
Czyli opcja fast forward.
Nawet jeśli nie ma potrzeby tworzenia commitów bo nie było żadnych konfliktów nie było żadnych zmian
tutaj i tak jest tworzony specjalny commit który jest miejscem łączenia tych dwóch gałęzi i jest okazją
na dodanie nowego message czyli opisanie co się stało tutaj ja tu zrobię
wq powstaje nowy commit git log oneline i teraz widzisz tu jest nasz commit który spójrzmy na gałęzi
ale zaraz po tym mam informację że została tutaj zmerge'owana ta gałąź i to pozwala później w historii
zobaczyć dokładnie kiedy kto i jakie commity dodawał i te numerki pozwolą także sprawdzić np. w naszym systemie
śledzenia zgłoszeń dokładnie o co chodziło czego dotyczył problem itd.
Czyli możesz po prostu dołączyć do historii bezpośrednio wszystkie twoje zmiany i mieć ładną historię
aczkolwiek niektóre zespoły preferują właśnie mieć taką historię w którym są te punkty łączenia gdzie
merge są jasno oznaczone i wiadomo dokładnie kiedy i jakie zmiany zostały dołączone do tej gałęzi dev
gdy taka gałąź dev zawiera nasze zmiany.
Możemy ją wypchnąć na zdalny serwer czyli git push.
Oczywiście w naszym przypadku poszło bez konfliktów bo w tym czasie nikt nic nie zmieniał jeśli w trakcie
naszej pracy pojawił by się konflikt to przy pullu lub przy pushu musielibyśmy go rozwiązać.
Ale to już wiesz jak zrobić z naszych poprzednich lekcji.
Ok czyli wypchnę zmiany na dev.
I te zmiany powinny pojawić się na stronie.
Git strona tutaj przejdziemy do gałęzi dev i możemy nawet porównać sobie zmiany czyli mogę porównać przed gałąź master
i dev zobaczyć dokładnie gdzie zostały wprowadzone zmiany i mogę nawet tutaj poprowadzić dyskusję
czy współpracę z innymi osobami mogę stworzyć pool request czyli zarządzać załączeniem tego do mastera.
Ale o tym wszystkim już w kolejnych lekcjach.
Do zobaczenia.