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!
We wcześniejszych lekcjach pracowaliśmy z jednym lokalnym repozytorium oraz z jednym zdalnym repozytorium.
Była to tak zwana praca z centralizowana lub workflow scentralizowany.
Czyli gdy wiele osób pracuje każdy na swoim komputerze ale integrują oni zmiany w jednym repozytorium
pracują na jednym repozytorium tworzą gałęzie w jednym repozytorium i łączą te gałęzie także w jednym repozytorium.
W tej lekcji pójdziemy do troszeczkę bardziej zaawansowanego schematu kiedy to zdecentralizujemy naszą pracę
na kilka repozytoriów czyli każdy będzie mógł pracować w osobnym repozytorium i dopiero na końcu dołączać
zmiany.
Takie podejście nie zawsze nie dla każdego jest najlepsze ale wymaga dodatkowych kroków dodatkowej pracy
przy małych zespołach scentralizowana praca jak najbardziej jest w porządku.
Natomiast przy dużych projektach projektach open source takich jak Git czy Linux czy inne projekty open
source mają wielu wielu współautorów i nie sposób jest zarządzać taką ilością osób dawać uprawnienia
sprawdzać czy na pewno zmieniły to co trzeba.
Dlatego rozdzielamy repozytorium na kilka jedno które zarządzane jest przez właściciela lub wybrane osoby
z uprawnieniami.
Natomiast pozostali współpracownicy pracują na własnych kopiach i wysyłają propozycje zmian które będą
uwzględniane dopiero w tym głównym repozytorium po zatwierdzeniu przez osoby odpowiedzialne za to właśnie
centralne repozytorium.
I teraz tutaj jestem zalogowany nie jako główny użytkownik tylko jako nasz git kolaborator.
Powiedzmy że git kolaborator z eduweb git chciałoby stworzyć takiego klona kopię ale nie tylko na swoim dysku
a także przechowywać ją na githubie.
Tutaj mamy taki przycisk nazywa się for Fork to jest skopiowanie stworzenie własnej kopii takiego repozytorium
od kogoś na swoim koncie na githubie.
Do tego nawet nie musimy instalować gita forka możemy zainstalować w każdej chwili z dowolnego projektu ja sobie tutaj.
Fork ten proces chwilkę trwa i większe repozytorium dłużej będzie się kupowało widelec i ksero taka kopia taki fork jak
widzisz tworzy identyczny projekt git strona ale tym razem nie znajduje się on u oryginalnego autora
eduweb git tylko jest git kolaborator czy na moim nowym koncie kopia jest przechowywana i tam informacja że została sforkowana
czyli pobrana z eduweb git git strona.
Ja mogę tak całe repozytorium sobie pobrać i zrobimy tak jak już wiesz poprzednio zrobimy tutaj HTTPS
przejdę do terminala.
Klon wkleimy tutaj nazwę to stronafork się pobiorą wszystkie nasze zmiany ok przejdziemy do katalogu strona
fork tutaj mamy zupełnie własną kopię całego projektu możemy dowolne zmiany wprowadzać i one nie zastaną odzwierciedlone
w oryginalnym repozytorium wpiszmy sobie git remote show origin.
To tutaj dostajemy tylko adresy nasze naszego projektu git kolaborator gitstrona.
Strona nie ma tu w ogóle wzmianki o tym skąd wzięliśmy ten projekt czyli z oryginalnego repozytorium.
Gitstrona i teraz tutaj możemy zupełnie samodzielnie pracować robić własny osobny projekt jednak prędzej czy później
będziemy chcieli pobrać najnowsze zmiany z oryginalnego projektu lub nasze zmiany także zintegrować
do głównego repozytorium.
Zacznijmy może od pierwszej części.
W jaki sposób ja mogę do tego repozytorium ściągnąć pobrać na przykład poleceniem git fetch zmianę zupełnie
innego repozytorium.
Przejdę do naszej strony na chwilkę przejdę do oryginalnego repozytorium eduweb git git strona.
I tutaj pobiorę sobie jeszcze raz adres do oryginalnego repozytorium i dodamy drugi adres drugiego serwera
drugiego repozytorium.
One mogą być na githubie oba albo mogą być w zupełnie innym miejscu tak długo jak jest to repozytorium git.
Robię git remote.
Dodajmy nowy ale tym razem nie będzie to origin bo origin jest to nasze konto czyli git kolaborator git
strona tutaj dodajemy tzw. upstream.
Ta nazwa jest dowolna upstream jest przyjętą po prostu konwencją jeśli widzimy gdzieś upstream to znaczy
że jest to serwer.
Jest to repozytorium które jest źródłowym naszym repozytorium z którego forkowaliśmy tak czyli tutaj dodaje.
Upstream w ten sposób i teraz zrobimy git remote.
Mamy tutaj dwa serwery.
Mam nasz serwer origin i mam serwer upstream.
I teraz jeśli powiedzmy pojawią się jakieś zmiany w tym repozytorium zdalnym ja bym chciał zintegrować
do mastera.
Najprostsza rzecz po prostu robimy git pull nie origin tym razem tylko upstream.
I tutaj master
i tutaj po pierwsze utworzona jest nowa gałąź upstream master czyli będziemy przechowywali sobie informację jak
wygląda sytuacja w naszym zdalnym repozytorium także do fetch zostały pobrane zmiany do fetch head i te zmiany
są zintegrowane z masterem.
Jeśli były by jakieś zmiany konfliktujące to by powstał konflikt który musielibyśmy rozwiązać i później zintegrować
to z powrotem z oryginalnym serwerem.
Jeśli okaże się że dość często popierasz zmiany z tego źródłowego repozytorium to wpisywanie za każdym
razem git pull upstream master może być troszeczkę męczące.
Co możesz zrobić to ustawić upstream czyli miejsce z którego mają być pobierane zmiany na stałe czyli robiąc
git branch set upstream
nazwa serwera czyli upstream np. master.
W ten sposób lub krócej po prostu literka u upstream master i w ten sposób ta gałąź nasza master jest ustawiona
żeby śledziła zdalną gałąź master z naszego serwera upstream czyli z oryginalnego repozytorium eduweb
git gitstrona z którego forkowaliśmy naszą wersję to się cofnie z powrotem git kolaborator
przejdziemy do naszej wersji czyli git kolaborator git strona która była sforkowana i teraz pobieram wszystkie
zmiany tego oficjalnego repozytorium integruje do mojej gałęzi master pracuje tak jak poprzednio na
tematycznej gałęzi gdy jest ta praca skończona mam dwie opcje albo mogę bezpośrednio spróbować taką
gałąź commitować do głównego repozytorium.
Chyba że nie jestem jedną z tych osób uprawnionych jeśli jestem jednym z pozostałych współpracowników którzy
nie mają takich uprawnień to co mogę zrobić mogę opublikować moje zmiany w moim repozytorium git strona
i poprosić by któryś z osób uprawnionych pobrał tę zmianę sprawdził i zintegrował je w oryginalnym repozytorium
czyli powiedzmy że jako kolaborator utworzę nową zmianę.
Przejdźmy do pliku powiedzmy że dam zupełnie nową sekcję także skopiowałem ten projekt i chce zaproponować żeby utworzyć
zupełnie nową sekcję w naszym projekcie i nazwać go dobre praktyki albo techniki pracy zespołowej powiedzmy
w ten sposób żeby tutaj dać taką nową sekcję do naszego naszej strony internetowej ja tutaj to zapisze i przejdziemy do
terminalu.
I oczywiście tu zrobimy na masterze prawidłowo powinienem zrobić git checkout.
Powinienem stworzyć nowy branch i powiedzmy nazwę go nowa sekcja sekcja i tu scommitujemy.
Czyli git commit.
Nowa sekcja i taką gałąź nowa sekcja wypchnę do naszego repozytorium czyli robimy git push origin nowa
sekcja możemy jeszcze ustawić żeby śledził ten branch i wypchniemy
taki branch na serwer ok.
Przejdę teraz na stronę tutaj mam informację że minutę temu powstał nowy branch nowa gałąź nowa sekcja i teraz co musielibyśmy
zrobić musielibyśmy poinformować któregoś z właścicieli lub współwłaścicieli oryginalnego naszego repozytorium
czyli tego repozytorium git strona eduweb git strona z którego forkowaliśmy żeby wszedł tutaj do nas żeby pobrał cały ten
branch sprawdził zmerge'ował go do gałęzi master abyśmy mogli my wtedy mogli z powrotem do gałęzi master zrobić pull pobrać
najnowszą wersję razem z naszymi zmianami i kontynuować prace dalej jest to dość pracochłonne.
Jak widzisz tutaj problem będzie z komunikacją bo trzeba będzie się dostać i poprosić.
Co ma zrobić gdzie i tak dalej.
Na szczęście tutaj github ma specjalną funkcję do tego dzięki czemu taki proces integracji wprowadzania
zmiany muszą przeprowadzić bezpośrednio ze strony githuba nie musząc nawet pobierać czy checkout'ować tych zmian do naszego
repozytorium.
W tym celu użyjemy pull request.
Ale o tym wszystkim już w kolejnej lekcji do zobaczenia.