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 udało nam się założyć konto na git hubie stworzyć pierwsze repozytorium z nazwami git
strona a następnie wszystkie nasze zmiany pliki wysłałem przy użyciu polecenia push doo właśnie tego tutaj
repozytorium i nasze repozytorium lokalne wiedziało gdzie te zmiany wysłać dlatego że podane ma w konfiguracji
właśnie ten adres URL który widzimy na git hubie czyli git hub nam stworzył specjalny adres pod którym wszystkie zmiany
które prześlemy pojawią się właśnie w tym zdalnym repozytorium.
I ten adres możemy podejrzeć przez naszego lokalnego repozytorium.
Pierwsza strona tutaj mam polecenie git config list i opcja local tylko mi lokalne pokażę z naszego repozytorium
ustawienia.
Jak się przyjrzymy tym ustawieniom tutaj o właśnie na dole mamy dwa razy adres podany właściwie jeden.
Tutaj mamy tylko adres tu dokładnie git hub eduweb strona czyli dokładnie ten sam adres który git hub nam podał ten adres
dodałem poleceniem remote do którego wrócimy i tutaj git skonfigurował mi właśnie informację o tym gdzie wysyłać
zmiany a także skąd pobierać zmiany i teraz poleceniem git pull mogę pobrać najnowsze zmiany poleceniem git push
wysłać spróbujemy zrobić git pull pokaże nam że jest up to date natomiast git push jak pamiętasz poprzednim razem
zapytał mnie o hasło to ja też zapytam o hasło teraz nie będę wpisywał tylko anuluję i zależy od twojego
systemu operacyjnego od konfiguracji jakie hasło może być przechowywane np. w Windowsie może być przechowywane
w systemie jakichś kluczy twojego Maca lub twojego Linuksa.
Jeśli masz zainstalowany jakiś inny program do zarządzania gitem on może zarządzać tymi hasłami.
Jest wiele innych możliwości aczkolwiek hasła jest z nimi kilka problemów.
Po pierwsze jeśli masz takiego menedżera haseł to musisz za każdym razem to hasło wpisywać.
Jeśli masz menedżer np. ja mam Windowsowy menedżer to żeby cokolwiek zmienić trzeba wchodzić w panel sterowania Konta
użytkowników zarządzanie poświadczeniami.
I tu gdzieś jest ja go już usunąłem.
Jeżeli mnie pyta o hasło jeszcze raz tutaj trzeba aż głęboko w tych ustawieniach i usuwać.
Więc proponuję tobie.
Jeśli chcesz skonfigurować tutaj inną metodę to panel sterowania w ten sposób wybrać któryś z tych kluczy
gdzie jest napisane git hub i po prostu usunąć go żeby mógł skonfigurować inną metodę w tej lekcji pokażę ci nieco inną dużo wygodniejszą
ale także bezpieczniejszą metodę autoryzacji logowania się w git hubie właśnie z poziomu gita i będą to tak zwane
klucze ssh jeśli nie korzystałeś nie korzystałaś wcześniej z kluczy ssh ani samego ssh do łączenia
się ze zdalnym serwerem tutaj krótko postaram się powiedzieć czym to jest na jakiej zasadzie to działa.
Następnie przejdziemy już do konfiguracji może od razu przejdę do strony git huba i tu jest ważna rzecz
bo git hub będzie potrzebował ustawienia tych kluczy.
I tutaj może u ciebie wygląda ten interfejs troszeczkę inaczej bo to się dużo często zmienia.
Tak to musimy znaleźć opcję opcje będą prawdopodobnie gdzieś tutaj w panelu użytkownika ja mam tutaj settings.
I tutaj gdzieś powinny być o właśnie ssh keys.
I tu jeszcze gpg jest kilka rodzai kluczy zajmę się tymi pierwszymi ssh.
I tutaj jeśli korzystamy z platformy typu git lab albo git bucket.
W zasadzie jest ona bardzo podobna także tworzysz konto tworzysz repozytorium także wchodzisz tutaj
właśnie w ustawienia i tam także gdzieś powinna być taka opcja jak ssh i klucze.
I tutaj mam informację że nie ma żadnych kluczy ssh dodanych do tego konta.
Gdybyś chciał właśnie wygenerować taki klucz to jest cała bardzo fajna informacja instrukcja na temat
tego jak takie klucze wygenerować tu jest dokładnie co to jest sprawdzanie istniejących generowanie
nowych kluczy.
Nim jednak wykonamy te polecenia chciałbym ci krótko powiedzieć na czym polega korzystanie z kluczy
Jeśli ja łącząc się z naszym serwerem np. z git hubem z naszym repozytorium to są jest dany komputer i muszę w jakiś sposób
komunikować się z nim.
Jedną z metod było pliki lokalne lub pliki sieciowe.
Inną opcją jak pamiętasz tutaj był protokół.
Protokół do wyboru https albo właśnie ssh.
Jak widzisz mogę oprócz tych dwóch różnych protokołów czyli sposobów komunikacji z serwerem się połączyć ja użyłem https
można używać ssh i ssh wymaga autentykacji.
I tutaj tak jak robiliśmy to wcześniej chciałem robić git push.
Pyta mnie o nazwę użytkownika pyta o hasło wysyła nazwy użytkownika i hasła do serwera serwer sprawdza
czy są OK.
Jeśli tak pozwala wysłać mi moje zmiany jeśli to jestem ja.
Problem z wysyłaniem haseł po sieci w ten sposób jest taki że jeśli powiedzmy ktoś byłby np. w naszej
sieci i byłby w stanie nasłuchiwać tego co wysyłamy no to jest ryzyko że ktoś podsłucha te nasze hasła
i to zostanie zdobędzie dostęp do naszego raporta będzie mógł w naszym imieniu wysyłać zmiany tak byśmy
nie chcieli.
Dlatego ja zastosuje klucze ssh.
Na tej stronie konfiguracji kluczy ssh mam przycisk dodawania nowego klucza ale także mam tu informacje z których możesz
dowiedzieć się więcej na temat właśnie kluczy ssh mianowicie jak je wygenerować ja je utworzę w nowej karcie.
Mam różne informacje.
Co to za ssh.
Jak to działa.
Tutaj możesz sprawdzić czy już masz jakieś istniejące klucze jeśli wcześniej korzystałeś z gita byś
mógł ten krok pominąć tutaj tutaj ja od razu przejdę do wygenerowania nowych kluczy i mamy opis co to jest jak to
wygląda.
Mam też polecenia które musieliśmy wykonać aby takie klucze wygenerować.
Jeśli pracujesz pod unixem takie polecenie powinno być dostępne np. pod Linuxem pod Macintoshem.
Jeśli pracujesz to Widnowsem pracujesz to razem z tym pakietem git for Windows który zastosowaliśmy te polecenia powinny być
dostępne w naszej konsoli bashowej.
Pozwolę sobie to polecenie tutaj wykonać.
Tutaj będę musiał podać nasz adres e-mail czyli skopiuj
ok i tutaj adres email to będzie eduweb git gmail com nasz tymczasowy adres.
OK to jak widzisz generuje nam parę kluczy.
I teraz jakim sposobem możemy obejść wysyłanie hasła loginu za każdym razem gdy ktoś go nie podsłuchał
jest tworzenie dwóch kluczy prywatnego i publicznego.
Tutaj pytał mnie on o hasło klucze będą służyć do podpisywania szyfrowania aczkolwiek chodzi o wygenerowanie
skrótu jakby krótkiego podpisu jeden podpis matematyczny czyli tak samo jak poszedł commit id.
Commita jest skrótem matematycznym z jego całej jego treści tak samo tutaj te klucze pozwolą wam pozwolą nam
każdą naszą zmianę każdy nasz pakiet zmian który chcemy wysłać do serwera właśnie podpisać.
Takim kluczem ale jedna różnica będzie taka że te klucze będą tutaj dwa publiczne i prywatne będziemy się chcieli
właśnie podpisać taką paczkę zapytać o hasło do tego klucza żeby ktoś inny na naszym komputerze nie
mógł podpisać naszych zmian.
Jeśli mam tutaj komputer dobrze zabezpieczony można pokusić się o pominięcie takiego hasła.
Wtedy nie trzeba będzie go za każdym razem wpisywać jednak tutaj możesz być pewien że nikt nie dostanie się do
twojego komputera i do twoich plików.
Ja tutaj właśnie zrobię tak czyli postawię puste hasło Enter i on tutaj w katalogu
C Users Nazwa użytkownika stworzy id rsa tutaj utworzymy katalog pyta o hasło zostawię
puste ponownie puste i teraz mam dwa pliki powstał plik katalogu ssh.
Powstał plik id rsa i w tym samym katalogu powstał drugi plik id rsa pub.
I teraz jeden z tych kluczy będzie naszym kluczem prywatnym i klucz prywatny będzie służył do podpisywania
czyli generowania specjalnej sumy kontrolnej specjalnego ciągu znaków które będziemy wysyłać razem z naszymi
zmianami.
I teraz każda osoba która ma odebrać nasze zmiany.
Nie chcemy wysyłać hasła bo byłoby to niebezpieczne.
Wyślemy nasze zmiany razem z takim podpisem ale ta strona odbierająca czy np. strona git hub będzie posiadała
nasz klucz publiczny i klucz publiczny służy do weryfikacji do sprawdzenia czy podpis czyli wygenerowany
specjalny ciąg znaków z naszych zmian jest prawidłowy i polega to na tym że klucz prywatny pasuje do
publicznego.
Mianowicie to co podpiszemy kluczem publicznym.
Jakie zmiany można sprawdzić później kluczem prywatnym.
Czy one naprawdę zostały wygenerowane razem ze sobą czy do siebie pasują.
Jest to bardzo fajny mechanizm bezpieczeństwa dlatego że nigdy nie wysyłamy kompletu naszych informacji
zabezpieczających.
Nigdzie zawsze tutaj pół informacji znajduje się na jednym komputerze pół na drugim komputerze.
Jeśli mamy zmiany dopiero połączenie tych informacji razem pozwala sprawdzić czy te zmiany faktycznie
są od nas.
Czy ta zmiana została stworzona przez uprawnioną do tego osobę ja wrócę z powrotem do dokumentacji.
Githuba tutaj mam informację że wygenerowano klucze tu mam informacje o katalogu który chcemy stworzyć o haśle
które zdecydowałam się zostawić puste dla naszej wygody.
I tutaj nie jest to zawsze konieczne ale też instrukcje jak dotrzeć do ssh agenta ssh agent ssh prawdopodobnie
powinien sam wczytać te klucze ale można także dla bezpieczeństwa.
Zobaczyć czy taki agent jest dostępny i poleceniem ssh agent s sprawdzam czy taki agent działa na porcie.
2 2 4 0 jeszcze mogę spróbować ssh agent samo są informacje tutaj różne na temat właśnie tego agenta na którym porcie tutaj jest dostępny
socket do komunikacji z tym agentem.
Jego proces czy na pewno on działa.
I jeśli on działa to możemy spróbować nasz klucz zarejestrować.
Czyli widzisz wykonuję polecenie ssh add czyli dodaj klucz i podaje ścieżkę właśnie do tego naszego
wygenerowanego pliku id rsa i teraz nasz prywatny klucz został dodany do naszego agenta na komputerze.
Natomiast drugą częścią klucza czy część publiczną spróbujemy tutaj sobie wyświetlić czyli zrobimy cat podam
tu ścieżkę do tego pliku i dopisze jeszcze pub.
Teraz ważne jest żeby tego prywatnego klucza żebyś przypadkiem nikomu nie pokazał na przykład gdybym tutaj zrobił polecenie
cat i wyświetlał zawartość pliku id rsa samego czyli prywatnego.
No to ktoś przypisując sobie taki plik z wideo mógłby w moim imieniu po prostu wysyłać commity i nasz
git hub mając ten klucz publiczny myślał by że te wszystkie komenty faktycznie pochodzą z zaufanego źródła
wyświetla świetle klucz id rsa publiczny tutaj mam identyfikator co to jest za klucz to jest ssh typu typu rsa szyfrowany
klucz tu jest cały nasz klucz on się kończy dwoma znakami równa się i tu jest adres e-mail z jakim ten
klucz został utworzony.
Całą zawartość tego pliku czyli od adresu tutaj od nazwy rodzaju klucza przez cały klucz po adres e-mail
to całe ja kopiuje wrócę teraz do git huba i tu mam opcję dodaj nowy klucz ssh nazwę go sobie szkolenie
git tutaj polecam nazywać go tak jak komputer dlatego że każdy klucz jakby jest tworzony dla innego komputera
jest generowany na podstawie komputera na którym jesteście oraz adresu e-mail dlatego jeśli masz kilka komputerów
tutaj każdy z nich będzie wymagał innego klucza.
Tak jest najlepiej w razie gdyby któryś twój komputer został ukradziony lub ktoś do niego się włamał to w ten
sposób nie ryzykujesz.
Jakby wszystkich wszystkich kluczy wystarczy że taki jeden taki klucz usuniesz i pozostałe klucze są bezpieczne
to warto go generować wiele różnych kluczy prywatnych publicznych i tutaj parę ich dodawać dzięki temu możesz
łatwo później brać taki zagrożony klucz usunąć tutaj dodaję treść sobie klucza klucza ssh OK.
Mamy tutaj klucz informacja że nigdy nie był użyty i teraz spróbuję tego klucza użyć i jak pamiętasz.
Tutaj dodawaliśmy nasz adres przy użyciu protokołu https.
Sprawdźmy to poleceniem git remote show.
Mamy tylko jedno źródło jest to origin i tutaj jak pamiętasz były adresy adresy zaczynają się od https i tutaj przy
każdym logowaniu on będzie nas pytał o użytkownika i hasło żeby korzystać z właśnie z protokołu.
Git tutaj albo protokołu ssh który pozwoli nam właśnie komunikować się przy użyciu certyfikatów żeby
ten adres zmienić.
Czyli tutaj powrócę jeszcze raz do naszej strony.
Tutaj gir strona i tutaj adres nie https tylko wybiorę sobie adres ssh i tutaj ustalimy go przy użyciu polecenia git remote set url origin.
I zmienię ten adres na ten adres ssh.
OK spróbujmy teraz zrobić git.
pull.
Jest up to date spróbuje wprowadzić jakąkolwiek zmianę czyli np. utworzę jakiś plik powiedzmy test
scommitujemy go.
Testowy plik a następnie spróbujemy zrobić git push aby nasz nowy commit wypchnąć na serwer i tu jak widzisz nie
było ani pytania o nazwę użytkownika nie było pytanie o hasło wszystko stało się automatycznie dlatego że git stworzył
taką paczkę wszystkich zmian do wysłania gdyż były to trzy obiekty trzy obiekty dlatego że prawdopodobnie
był to nowy plik był to plik drzewka zmieniony i był to plik naszego nowego Commita.
Jak widzisz git próbuje kompresować ma korzystając ze wszystkich rdzeni jaki nasz procesor posiada jest bardzo
wydajny kompresuje żeby te pliki wysyłane mniej zajmowały wysłał pliki wysłał trzy pliki.
Tutaj jak widzisz serwer rozwiązał różnicę czyli zaakceptował te zmiany zintegrował je z repozytorium i tutaj podany
jest adres do naszej aplikacji mamy także informacje które commity zostały zmienione i który branch zobaczmy
także co się tutaj zmieniło u nas w git hubie.
Przejdę do zakładki commits i jak widzisz u nas testowy plik znajduje się w tym miejscu.
Jest to dużo wygodniejsze bo nie muszę co chwilę podawać użytkownika i hasło logować się ale także nie wysyłam
tych informacji poprzez internet.
Czyli nie ma ryzyka że ktoś przechwycił informację za każdym razem gdy wysyłam jakieś zmiany podpisuje
je i za każdym razem ten podpis jest inny.
Natomiast tutaj ten serwer na przykład nasz git hub posiada nasz klucz publiczny dzięki którymu można łatwo taki podpis
podpis zweryfikować i sprawdzić czy na pewno to my czyli autor właściciel oryginalnego podpisu prywatnego
na pewno podpisał ten plik i dzięki temu możemy bezpiecznie tutaj wysyłać zmiany na githuba.
Czyli po tej lekcji wiesz już że możesz pliki pobierać i wysyłać z git huba korzystając z różnych protokołów
może być https może być to ssh ale także możesz korzystać z różnych sposobów logowania.
Możesz podawać użytkownika i hasło możesz zapamiętać w jakimś menedżer haseł np. w Windowsowym Menedżerze
haseł lub w jakimś zainstalowanym w twoim innym systemie operacyjnym.
Ale jak widzisz najwygodniejszą metodą jest metoda używania kluczy ssh.
Są to klucze dzielone na część publiczną i prywatną.
I każda nasza zmiana jest podpisywana i jest weryfikowana przez serwer.
Dzięki temu jest to wygodne bo nie muszę podawać użytkownika i hasła a z drugiej strony jest to bezpieczne
bo ten użytkownik to hasło nie są nigdy wysyłane poprzez internet.
To tyle jeśli chodzi o konfigurację kluczy w kolejnych lekcjach zajmijmy się właśnie pracą już zdalną i współpracą.
Wielu użytkowników z jednym repozytorium właśnie przy użyciu takiego portalu jakim jest github do zobaczenia.