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 w poprzednich lekcjach korzystaliśmy z płacenia git.
Remote aby konfigurować w jaki sposób nasze lokalne repozytorium będzie komunikowało się z danym serwerem.
Jeśli wpisze samo polecenie git remote albo wpisze git remote show w ten sposób wyświetla mi się lista zdalnych zasobów z danych
repozytoriów.
I taką domyślną główną nazwą podobnie jak dla gałęzi jest to master tak dla zdalnych repozytoriów
jest to Origin Origin jest takim podstawowym głównym pierwszym źródłem naszego projektu.
I jeśli wpisze git remote show i podam nazwę tego repozytorium będzie to origin tutaj wyświetlą się wszystkie
szczegóły dotyczące tego repozytorium czyli jest to zdalny jakiś zasób repozytorium.
Nazywa się ono Origin i tu ma dwa adresy jest to adres fetch i push czyli adres do pobierania i wysyłania.
U nas jest to dokładnie ten sam adres ale moglibyśmy ustawić dwa różne adresy i np. jeden adres mógłby być w
takim oficjalnym głównym repozytorium z którego pobieramy wszystkie najnowsze zmiany w naszym projekcie.
Natomiast ten push URL mógł być jakimś specjalnym dodatkowym repozytorium np. takim repozytorium które
jest poddawane dodatkowej weryfikacji czy np. przeprowadzony jest przegląd kodu i może mieć taki kilkustopniowy
proces gdzie na jedno reporterom wysyłamy zmiany ktoś je weryfikuje akceptuje przysyła na to główne
repozytorium z którego my ściągamy zmiany.
U nas ten proces będzie dużo prostszy będziemy wysyłać i pobierać zmiany dokładnie z tego samego repozytorium.
Tutaj dodatkową informacją jest która gałąź jest gałązią head czyli jak pamiętasz jest to czubek naszej
historii zmian początek naszej historii zmian i tutaj na zdalnym repozytorium.
Master jest właśnie ustawiony tym headem czyli branch master.
Jest tą gałęzią która wskazuje na początek tego danego zasobu i tu mam też informacje o wszystkich
branchach wszystkich gałęziach które są śledzone i teraz co oznacza że gałąź jest śledzona.
Możemy powiązać naszą lokalną gałąź na przykład gałąź master ze zdalną gałęzią master czyli na przykład gałęzią master
która znajduje się tutaj w tym repozytorium git strona na naszym serwerze git hub.
I w ten sposób jeśli gałąź jest śledzona możemy bardzo łatwo zsynchronizować te gałęzie możemy zmiany
z jednej gałęzi pobrać do drugiej a następnie zmiany które utworzyliśmy lokalnie możemy wypchnąć bardzo
łatwo do takiej gałęzi.
Czyli jest to gałąź która po prostu podąża śledzi lub inaczej synchronizuje się z daną gałęzią.
Oczywiście te zmiany ta synchronizacja nie dzieje się samoczynnie automatycznie wykonuje się przy użyciu poleceń pull
i push które będziemy omawiać w kolejnych lekcjach i tutaj jak widzisz też mam informację że lokalny branch
jest skonfigurowany do automatycznego git pull czyli jeśli będziemy chcieli pobrać zmiany to nie musimy
wpisywać dokładnie jaką gałąź z jakiego repozytorium chcemy pobrać do jakiej gałęzi.
Wystarczy że będąc na gałęzi master wpiszemy polecenie git pull i on automatycznie pobierze wszystkie zmiany
z naszego repozytorium.
I tutaj wszystkie zmiany są zmerge'owane tutaj z lokalnym master będzie zmerge'owany ze zdalnego mastera i vice versa.
Widzisz jest to także skonfigurowane by polecenie git push bez dodawania dodatkowych parametrów bezpośrednio
wypchnęło nam zmianę.
W ten właśnie w tę gałąź która jest właśnie trakowana czy jest synchronizowana z naszą gałęzią jak widzisz
mam tutaj tylko jedno zdalne repozytorium.
Jest tu ono podane pod nazwą origin i jest to nasze repozytorium na git hubie.
Pokażę ci jak możesz bardzo łatwo do jednego repozytorium lokalnego dodać kilka zdalnych adresów np.
by tworzyć kopię zapasową lub np. by mieć adres z którego pobiera się na przykład zmianę jeśli jest
on przed publiczne jakieś repozytorium open source którego nie chcesz zmieniać i swój adres na którym
publikujesz jakieś swoje zmiany których nie chcesz jeszcze publikować z danego repozytorium.
Możliwości jest wiele.
Pamiętaj tylko że właśnie dzięki tej konfiguracji remote możesz jedną swoją jedno repozytorium podłączyć
do kilku zdalnych repozytoriów a każdą gałąź każdy branch będzie twoim repozytorium lokalnym możesz jakby spiąć
powiązać z dowolną inną gałęzią na dowolnym zdanym repozytorium.
I tutaj dla przykładu ja utworzyłem na innym portalu mianowicie na bin buckecie także użytkownika eduweb git
utworzyłem mu przykładowe repozytorium tak że nazywa się pierwsza strona.
I tutaj jako główny panel powitany ma informację że tu nie ma żadnych jeszcze plików czyli bardzo podobnie
jak na git hubie tu ma opcję zaczynam od początku lub mam istniejący projekt.
Ja już mam projekt.
Jak widzisz tam polecenie git.
Remote cat origin ja tu przekopiuję sam adres.
Mógłbym także przekopiować.
Właśnie z góry i jak widzisz bardzo podobny jest ale jest tutaj inny adres bo jest to inny serwer i mogę taki
adres dodać pod inną nazwą lub pod tą samą.
Ja zostawię tutaj ten Origin który mamy dlatego że będziemy dalej pracować z git hubem.
Nie mogę tego przekopiować tak jak jest w tej linii.
Przekopiuję sam adres i dodamy drugi remote pod inną nazwą czyli poleceniem git remote add tutaj podaje
nazwę tego drugiego remote czyli danego zasobu.
Nazwę go bit bucket żebyśmy wiedzieli dokładnie co to jest i tutaj wklejam adres.
Dodałem to w ten sposób i zobaczmy jeszcze raz jak będzie się różniło polecenie git remote jak widzisz mam teraz
dwie opcje mamy git remote origin i git remote bitbucket spróbójmy git remote show bitbucket
jak widzisz tu jest troszeczkę prościej.
Mamy mniej informacji dlatego że to remote origin jest tym repozytorium na którym branch master gałąź master
jest śledzony i traktowany czyli jak widzisz gałąź master jest ustawiona żeby zarówno pobierać i wysyłać zmiany do
tego Origin.
Natomiast tutaj jak widzisz head branch jest nieznany czyli nie mamy żadnych informacji o tym co jest na tym
repozytorium dlatego że jeszcze się nie łączyliśmy do niego i tutaj dodatkowo mam tylko fetch i push URL.
Nie mamy tych informacji o śledzeniu co możemy zrobić możemy wykonać polecenie push ręcznie to znaczy
podać mu dokładnie wszystkie informacje.
Czyli poleceniem git push nie origin tylko tym razem wpisze bit bitbucket czyli dokładnie tak jak nazwa
tego zasobu zdalnego.
I git push bit bucket bitmaster.
Czyli teraz chcę naszą gałąź Master wypchnąć do gałęzi master na serwerze bitbucket,czyli bardzo fajną rzeczą
jest to że ja mogę dowolnie nazywać serwery i na przykład mogę te same polecenia wykonywać na przykład Origin
Origin Origin a za każdym razem mogę w komplecie wstawić inny adres serwera inną konfigurację tego serwera
jesteśmy jakieś skrypty ustawienie jakiejś autoryzacji.
Nie trzeba wszędzie podmieniać adresu wystarczy po prostu podać wszędzie nazwę adres podajemy konfiguracji.
Tutaj zmiany nam się wysłały mamy 48 obiektów zobaczmy co się zmieni w naszym panelu na stronie bitbucket.
Tu już pojawiły się wszystkie komitety.
Interfejs jest troszeczkę inny ale zasada działania jest bardzo podobna.
Być może też inaczej wygląda to że portale zmieniają się tutaj też dodawane jest zmieniane zmieniane są
style.
Niemniej tutaj powiem zakładka commits jak widzisz są wszystkie nasze zmiany od początku i zakładka source w którym
widzimy nasz kod źródłowy.
Czy jak widzisz w ten sposób bardzo łatwo można np. stworzyć sobie kopię zapasową lub zarządzać np. mamy
kilka zespołów mamy jakiś inny proces deweloperski.
Możesz na jednym serwerze lub na kilku serwerach dowolna jest możliwość konfigurowaniu tych zdalnych repozytoriów
wyczyszczę ekran nie zawsze chcemy pobierać aż wszystkie informacje przeważnie bardzo często chcemy podać
komuś adres z którego pobraliśmy zmiany lub tam gdzie właśnie wysyłamy przechowaliśmy zmiany żeby ktoś
mógł sobie jakie dane pobrać i to jest polecenie bardzo szybkie.
Git remote np. nazwa remote naszego czyli Origin i tu wpiszemy git remote get URL Origin.
Jak widzisz to błyskawicznie daje od razu nam na adres nie trzeba przeszukiwać szukać.
Jk widzisz jest on dużo szybszy on nie sprawdza statusu tego całego zasobu w takich polecenia widzisz tylko i wyłącznie
adres.
Więc może by nawet je pokonać automatycznie i np. przekierować np. nazwę do jakiegoś pliku powiedzmy
adres txt?
Zobaczmy sobie plik adres txt zawierał nasz adres.
Dodatkowo możemy także robić to w drugą stronę.
Mogę zrobić git remote set url i podać inny adres ja tego adresu.
Nie będę zmieniał ale także jest to szybki sposób na przełączanie się z jednego repozytorium.
Gdybyśmy chcieli się szybko przenieść z bitbucketa np. na git huba z git huba na git laba czy jeszcze inaczej.
Po prostu dodajemy drugi Origin albo jeszcze prościej zmieniamy URL tego Origina na którym jesteśmy.
Wypychamy wszystkie zmiany i już nasze pliki nasze zmiany cała historia znajduje się na innym repozytorium.
Tutaj także mam opcję git remote rename i tego originu nie będziemy zmieniać ale możemy np. bitbucket
zmienić na przykład back up sprawdźmy teraz git remote zmieniłem nazwę tego drugiego z danego zasobu
na back up.
Widzisz też łatwo jednym poleceniem można taką nazwę zmienić i poleceniem git.
Remote remove back up.
Tutaj usuwamy cały taki zasób z konfiguracja oczywiście nie są skasowane żadne pliki nie są kasowane żadne
commity.
Jedyne co to tak naprawdę usunąłem stąd to konfigurację czyli tutaj wszystkie nasze zmiany pozostają bezpieczne zarówno
na git hubie jak i na bitbucketcie.
Po prostu odpieliśmy w ten sposób całe repozytorium od naszego lokalnego repozytorium.
Jeśli ponownie uruchamię polecenie git remote show origin żeby wyświetlić wszystkie informacje jak pamiętasz
mamy informację że nasza gałąź master jest skonfigurowana żeby zarówno polecenie git pull i push bezpośrednio
pobierały i wysyłały informacje nasze zmiany z odpowiadającej jej gałęzi na serwerze origin czyli na
git hubie
I także na tym serwerze z gałęzi która nazywa się master.
Tutaj oczywiście możemy dla innej gałęzi skonfigurować odpowiednio gałęzie zdalne żeby się zsychronizowały
w sumie poleceie git puli i push będą mogły łatwo z niego korzystać ale o tym już opowiem w kolejnych lekcjach.
Do zobaczenia.