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 poprzedniej lekcji do naszej strony dodaliśmy nową sekcję.
Tutaj jak widzisz w logu mamy nowy commit nowa sekcja.
Jesteśmy do przodu przed gałęzią origin master przed naszą gałęzią lokalną master oraz także przed naszą gałęzią
upstream master czyli jak pamiętasz gałęzią z której sklonowaliśmy z której skopiowaliśmy lub inaczej mówiąc
sforkowaliśmy nasze repozytorium tutaj przejdę także do edytora i nasze zmiany są tutaj widoczne techniki pracy zespołowej.
Nowa pozycja w spisie treści.
Te zmiany są scommitowane w naszej lokalnej gałęzi.
Chcieliśmy je wypchnąć do naszego konta na githubie czyli do naszego git kolaborator git strona.
I tych zmian naszych nie będziemy push'ować do oryginalnego repozytorium eduweb git git strona.
Bo załóżmy że tam nie mamy dostępu.
Załóżmy że my współpracujemy ale nie mamy od autora oryginalnego repozytorium uprawnień do commitowania
do pushowania tam zrobimy więc odwrotnie.
Scommitujemy tutaj spushujemy do tego repozytorium.
A następnie stworzymy nowy pull request czyli zapytanie lub żądanie dołączenia naszych zmian u siebie w tym
oryginalnym repozytorium.
I taki autor tego repozytorium z którego forkowaliśmy będzie mógł przejrzeć takie zmiany i zdecydować
czy chce faktycznie dołączyć byś mógł zrobić to bezpośrednio ze strony github przejrzeć zmiany ewentualnie
zaproponować jeszcze jakieś zmiany poprosić żebyśmy jeszcze wprowadzili jakieś zmiany.
Jeśli nie będzie żadnych konfliktów będziemy mogli jednym przyciskiem te zmiany wprowadzić.
Ok czyli spróbujmy to zrobić i zaczniemy oczywiście od wypchnięcia naszych zmian do naszego repozytorium
git kolaborator przejdę do wiersza poleceń jesteśmy na gałęzi nowa sekcja która tu znajduje się bezpośrednio
zaraz po gałęzi master także tej zdalnej gałęzi master do której będziemy chcieli stworzyć właśnie tego
pull requesta czyli tutaj robimy git push i ta gałąź powinna być ustawiona już na wypychanie właśnie do naszej
gałęzi origin master origin.
Nowa sekcja zobaczymy tak utworzyła tak utworzyła gałąź nowa sekcja i jeśli przejdę teraz na stronę tutaj naszą
git stronę odświeżę to jak widzisz pojawiła się informacja że niedawno wypchnąłem nowe gałęzie i gałąź
nowa sekcja pojawiła się mniej niż minutę temu i teraz mogę taką nową scommitowaną gałąź porównać z
istniejącą gałęzią i stworzyć pull request mam tu przycisk do pull request.
I teraz mogę stworzyć pull requesta do innej gałęzi w moim repozytorium aby inna osoba z którą pracuję
weszła i zdecydowała czy te zmiany połączyć czy nie ale mogę jak stworzyć także takiego pull requesta
pomiędzy różnymi repozytoriami na przykład tutaj od razu wybrało za mnie base fork.
Czy on wie że z tej strony pobierałem zmiany więc prawdopodobnie do tej będę tą propozycję wysyłał.
Czyli tak jak już tutaj mamy eduweb git git strona z tą stroną będziemy chcieli porównać i może nie do mastera tylko zaproponujemy
żeby do deva dołączyć taką gałąź i wtedy naszą gałąź git kolaborator git strona.
Nowa sekcja będę chciał zmerge'ować do dev ale nie będę tego robił.
Ja tutaj jak widzisz jest sugestia żeby osobą przeglądającą czyli reviewer był eduweb git.
Tutaj dołączyłem żeby ta osoba przejrzała czyli nasz drugi użytkownik mogę też przypisać tutaj siebie
że ja jestem odpowiedzialny.
Gdyby ten eduweb git miał jakieś pytania chciał porozmawiać zapytać to będzie wiedział do kogo ma się zgłosić
w sprawie tego pull requesta oraz różne inne funkcje tej współpracy funkcje społecznościowe
jakie posiada github.
My skupimy się na tej części musimy opisać o co chodzi w naszym pull requestcie jeśli on nasz integrator
ma dużo takich pull requestów to ważne żeby ta informacja była krótka najlepiej by ta informacja wyglądała tak jak
message do tego merge'a tak czyli tutaj chcemy informację jak wyglądał commit jak wyglądał merge commit taki tytuł jakbyśmy mu dali
najlepiej nazwać czyli nowa sekcja
do strony i nasza sekcja nazywała się techniki pracy zespołowej.
Więc to wszystko też umieszczę tutaj może dodatkowy opis stworzyć i ten opis może zawierać tutaj nawet
specjalne znaki specjalne formatowanie.
Na przykład bardzo ważna sekcja mogę się tutaj użyć pogrubienia tego typu rzeczy.
I tutaj stosujemy tzw. mark down czyli specjalny sposób formatowania tutaj klikniesz selecting them i learn more.
Możesz także dowiedzieć się więcej na temat tego zapisu.
To jest tak że podgląd może być np. dwie gwiazdki pogrubiają.
To jest ważna informacja bo to pomoże osobom współpracującym i osobom integrującym te twoje zmiany dowiedzieć
się o co chodzi w tej twojej zmianie i czy ją zintegrować jak ją zintegrować do której gałęzi tutaj poniżej masz
informacje ile commitów chcemy.
Proponujemy dołączyć ile plików zostało zmienionych w ramach tej propozycji.
I tu mamy jeszcze komentarze i osoby współpracujące.
Jak zobaczysz takie pull request jak otworzymy może wiele osób później dodawać do niego kolejne zmiany.
Czyli tutaj mamy tak jeden zmieniony plik.
Dane usunięte.
Tu mamy także diff czyli jak pamiętasz porównanie różnic pomiędzy wersjami możemy sobie przejść dokładnie
które zmiany zostały wprowadzone jeśli ktoś zintegruje ten właśnie pull request ok.
Stwórzmy taki pull request.
Wszystko się zgadza OK
OK.
Mamy git kolaborator chciałbym zmerge'ować jeden commit do eduweb git z git kolaborator nowa sekcja mamy też
konwersację commity i zmienione pliki.
Ja teraz przejdę tu jestem na stronie git eduweb.
Strona i mam uprawnienia do tej strony jeśli bym nie miał to mógłbym także podejrzeć tą stronę z drugiej
perspektywy.
Mianowicie tu zmienię użytkownika.
Tym razem jestem zalogowany jako eduweb git.
I tu jeśli przejdę do pull request jak widzisz tutaj pojawił się nowy otwarty pull request stworzony przez git kolaborator
mogę przejść do środka.
Jak widzisz taki właściciel także ma informację że właśnie git kolaborator prosi o dołączenie nowego commita do gałęzi dev
tutaj z gałęzi.
Nowa sekcja tu oczywiście możemy te dane jeszcze edytować możemy zmienić np. tytuł tutaj mam informacje
które zostawił nam git kolaborator o co chodzi.
Co się po kolei działo.
Całą historię zmian.
Tu mam wszystkie parametry który były ustawione możemy w tej dyskusji dołączyć.
Tutaj jednak nie będziemy wchodzić w dyskusję.
Jeśli podejrzę sobie jeden commit podejrzę zmienione pliki stwierdzam wszystko jest w porządku możemy to zostawić
w ten sposób.
Jeśli wszystko mi się podoba to mogę taki zestaw zmian połączyć z naszym repozytorium
czyli zmerge'ować mam kilka opcji może być po prostu merge commit czy tak jak robiliśmy merge no fast forward.
Stworzmy osobny commit z wiadomością z message co to są za zmiany i pojawi nam się tutaj ta zmiana jako po prostu
merge commit w naszej gałęzi dev o którą prosił nasz git kolaborator mam jeszcze dwie opcje squash and merge.
Czyli tak jak powiedzieliśmy git rebase pozwolą nam połączyć wiele commitów w jeden tutaj github zrobi to za nas połączy
wszystkie commity akurat u nas jest tylko jeden gdyby było ich więcej musimy wszystkie połączyć commity w jeden i zmerge'ować także
do gałęzi dev.
Mamy także opcję rebase czyli będziemy mogli tak jakbyśmy w przedostatniej lekcji zrebase'ować czyli wszystkie
nasze zmiany odłożyć na bok zaaplikować je jakby na zmianach z gałęzi dev.
Jeszcze raz tutaj także nie będzie potrzebne bo jesteśmy na bieżąco.
Nie ma potrzeby rebase'a tam jest także najzwyklejsza opcja merge commit.
Pamiętasz jak działają.
Tak tutaj jest opcja z rebase'owaniem czyli po prostu ze zmianą ilości commitów lub ze zmianą kolejności commitów my zrobimy
zwykły merge commit.
Tutaj klikam merge pull request i mam okazję dodać message do takiego commita taki tutaj message pojawi nam się właśnie
w git logu czyli spróbujmy confirm merge.
OK.
I tutaj mamy informację że eduweb merge commit into eduweb git dev just now i jeśli teraz przejdziemy do terminala naszego głównego
autora strony.
Zrobimy git pull tu są zmiany git log.
I tu jest gałąź master.
Muszę przełączyć na gałąź dev.
OK.
I jak widzisz nasz merge pull request z numerkiem tutaj od git kolaborator nam się pojawił.
Jak widzisz taki merge ma bardzo dokładny opis wiadomo od kogo przyszedł i ten numerek tutaj także pozwoli
nam odnaleźć tego pull requesta.
Przejdziemy do git strona i jeśli przejdziemy do gałęzi dev commity zobaczymy to tutaj jak widzisz ta dwójka
ma specjalne znaczenie.
Ta dwójka z numerem pull requesta jak widzisz na stronie mogę go kliknąć mogę kliknąć link i w ten sposób mogę powrócić do oryginalnego
pull requesta i przeczytać dokładnie jaka jest historia tego merge'a kto stworzył oryginalną propozycję
jaka była dyskusja jak odbywały się zmiany i kto zaakceptował te zmiany.
Tak wiec widzisz w ten sposób możemy dokładnie prześledzić w jaki sposób które zmiany pojawiły się w
naszym projekcie.
Jak widzisz dzięki pull requestom taka osoba odpowiedzialna za zarządzanie repozytorium zintegrowania zmian
tutaj nie musi nawet wychodzić do swojego terminalu.
Może te wszystkie operacje wysłania pobrania zmian ich przejrzenia i zaakceptowania.
I wiele wiele więcej i te rzeczy tutaj może zrobić właśnie ze swojego panelu na stronie github właśnie bez wychodzenia
do terminala bez innych tego typu narzędzi.
Github także kryje w sobie wiele narzędzi do współpracy do wymiany informacji do dyskusji ale o tym już
w kolejnych lekcjach do zobaczenia.