kleindan.dev

Praca z Git na maszynie wirtualnej

Na tej lekcji przejdziemy krok po kroku przez konfigurację systemu kontroli wersji git na naszej maszynie wirtualnej, łącznie ze skonfigurowaniem dostępu do naszego repozytorium na platformie GitHub i GitLab.

Wideo towarzyszące

Git i inne systemy kontroli wersji

Git jest obecnie najpopularniejszym systemem kontroli wersji wykorzystywanym w profesjonalnym i amatorskim programowaniu. Git ma swoje wady, zalety i sporo nieoczywistych rozwiązań, ale rozwiązuje kilka problemów:

Istnieją inne systemy kontroli wersji, które rozwiązują te problemy i jest spora szansa, że napotkacie je na ścieżce swojej kariery zawodowej, ale na chwilę obecną skupimy się na jednym wspólnym rozwiązaniu.

Pobieranie publicznych repozytoriów

Jeżeli korzystasz z maszyny skonfigurowanej pod ten kurs, git powinien już być na niej zainstalowany. Możesz to sprawdzić używając komendy:

> git version

Możesz też pobierać kod z publicznych repozytoriów nie konfigurując go w żaden sposób. Jeżeli chcesz pobrać repozytorium z kodem do tego kursu, w linii komend możesz użyć następującego polecenia:

> git clone https://github.com/ehmeth/pzaw-code.git

UWAGA Jeżeli jesteś w katalogu domowym na przygotowanej przeze mnie maszynie, jest spora szansa, że repozytorium jest już pobrane. Możesz usunąć katalog z repozytorium i pobrać je na nowo:

W nomenklaturze gita pobieranie lokalnej kopii innego repozytorium nazywa się klonowaniem repozytorium, stąd nazwa komendy git clone.

> cd ~
> rm -rf pzaw-code
> git clone https://github.com/ehmeth/pzaw-code.git

Albo możesz pobrać nową zawartość z serwera GitHub w ten sposób:

> cd ~/pzaw-code
> git pull

Tworzenie własnego repozytorium

Korzystając z interfejsu webowego utwórz nowe publiczne repozytorium na swojej ulubionej platformie z repozytoriami git a następnie pobierz je na swoją maszynę witrualną.

Sam proces tworzenia repozytorium jest dość prosty i wymaga podania nazwy oraz potencjalnie wyboru kilku dodatkowych opcji konfiguracyjnych w zależności od wybranej platformy. Jeżeli się zgubisz, odsyłam do filmu z początku tej lekcji.

Proponuję sklonować swoje repozytorium do katalogu domowego na maszynie wirtualnej:

> cd ~
> git clone <link do repozytorium>

Ostatnim krokiem jest otwarcie nowo utworzonego folderu w VS Code używając polecenia “File: Open Folder”

Podstawowa konfiguracja Git na VM

Na tym etapie jeżeli wprowadzimy jakiekolwiek zmiany w folderze, VS Code wykryje je i pozwoli nam je zsynchronizować z centralnym repozytorium na zewnętrznym serwerze naszej platformy git. Żeby faktycznie móc to zrobić, musimy wykonać jeszcze jeden krok konfiguracji.

Najmniejszą jednostką zmiany w git jest tzw. commit. Commit oprócz zmian wprowadzonych w plikach zawiera kilka dodatkowych informacji:

Zazwyczaj konfigurujemy git w taki sposób, żeby zawsze wykorzystywał te same dane jako naszą tożsamość dla wszystkich repozytoriów, możemy to zrobić używając komend:

> git config --global user.name "Imie Nazwisko"
> git config --global user.email "[email protected]"

Po tej konfiguracji możemy stworzyć nasze pierwsze zmiany w lokalnym repozytorium.

Czego nie umieszczać w repozytorium i .gitignore

System kontroli wersjii powinien przechowywać kod i informacje potrzebne do jego uruchomienia. Chcemy aby w naszym repozytorium znalazły się:

Nie chcemy aby w naszym repozytorium znalazły się:

Do kontrolowania tego, co będzie przechowywane w naszym repozytorium służy plik .gitignore. Jeżeli podczas tworzenia swojego repozytrium nie skorzystałeś z opcji stworzenia takiego pliku z domyślnymi ustawieniami, to zawsze możesz go utworzyć samemu.

Póki co nasze projekty nie zawierają zbyt wielu plików i zewnętrznych zależności, więc nasz bardzo minimalistyczny plik .gitignore może wyglądać w ten sposób:

> .gitignore
# npm external dependencies
node_modules/
*.log

Linie zaczynające się od znaku # to komentarze i mogą zawierać potem dowolną treść

W kolejnej linii informujemy git żeby nie dodawał do kontroli wersji katalogu node_modules i całej jego zawartości. Zwróć uwagę na znak /, bez niego git nie będzie wiedział, że ta linijka dotyczy katalogów.

W ostatniej linii, każemy ignorować wszystkie pliki z rozszerzeniem .log. Znak * oznacza dowolny ciąg znaków.

Jeżeli chcesz się dowiedzieć więcej na temat składni plików .gitignore i tego jak git z nich korzysta, jak zwykle polecam przeczytać dokumentację.

Pierwszy commit

Wszystko, co będziemy teraz robić da się osiągnąć używając komend w terminalu, jednak VS Code oferuje dość wygodny i przejrzysty interfejs, więc skorzystajmy z tego. Przejdź do widoku Source Control w VS Code (View -> Source Control albo skrótem Ctrl+Shift+G).

Git zakłada, że możemy pracować nad wieloma fragmentami naszej aplikacji równolegle, więc domyślnie wszelkie zmiany wykryte w repozytorium nie będą dodane do commita. Musimy ręcznie wskazać, które pliki mają być częścią commitu. Zmiany tak oznaczone git nazwywa staged.

W widoku Source Control znajdź drzewko changes i dodaj wszystkie zmiany do statusu staged używając przycisku Stage all changes.

Następnie dodaj w polu Messege opis swoich zmian i wciśnij przycisk Commit.

Gratulacje, stworzyłeś swój pierwszy commit! Teraz spróbujmy go wypchnąć w świat.

Synchronizacja z publicznym repozytorium

Publiczne repozytoria na GitHub i innych platformach pozwalają na pobieranie z nich kodu, ale prawo do zmiany jest domyślnie ograniczone do właściciela repozytorium.

Przez ostatnie lata wiele się zmieniło w kwestii bezpieczeństwa aplikacji internetowych i większość platform serwujących repozytoria git nie pozwala na logowanie się z linii komend czy innych narzędzi git przy pomocy loginu i hasła. Z punktu widzenia bezpieczeństwa to bardzo dobry wybór, bo zmniejsza to ryzyko, że ktoś uzyska dostęp do naszego konta. Ponieważ repozytoria na tych platformach są często powiązane z serwerami w chmurze i wprowadzenie do nich zmian przez osoby nieuprawnione mogłoby spowodować dla użytkowników bardzo realne straty finansowe. Z punktu widzenia wygody użytkownika niestety oznacza to, że musimy sobie jakoś poradzić.

Możemy ten problem rozwiązać na kilka sposobów, ja proponuję wykorzystanie tzw. access tokens. Są to długie ciągi znaków, które platformy serwujące nasze repozytoria łączą z naszym kontem i konkretnymi uprawnieniami. Są one dostępne zarówno na GitHubie jak i na GitLabie.

Proces tworzenia takiego tokenu jest pokazany w filmie załączonym do tej lekcji. Utwórz własny token z odpowiednimi uprawnieniami i zapisz go w bezpiecznym miejscu.

UWAGA Aby uniknąć próby logowania się do GitHuba przez VS Code bezpośrednio, wyłącz w ustawieniach VS Code ustawienie: GitHub: Git Authentication.

Następnie podczas próby synchronizacji z zewnętrznym repozytorium VS Code zapyta nas o nazwę użytkownika i hasło. Zamiast hasła należy podać pełny access token.

Jeżeli wszystko poszło dobrze, to po wejściu na stronę swojego repozytorium powinieneś widzieć swoje zmiany.

Bezpieczeństwo access tokenów

Jeżeli mamy poprawnie skonfigurowany token dostępowy, nawet jeżeli ktoś nieuprawniony zdobędzie do niego dostęp, nie powinien mieć możliwości wyrządzenia wielkich szkód na naszym koncie. Pod tym względem tokeny platformy GitHub są trochę bezpieczniejsze, bo możemy w nich ograniczyć dostęp do konkretnego repozytorium.

Mimo to token powinien być przechowywany w sposób bezpieczny, osobiście swój przechowuję w sprawdzonym menadżeże haseł.

Maszyna wirtualna przygotowana pod ten kurs jest dodatkowo skonfigurowana tak, żeby przechowywać access token w pamięci przez 90 minut od wpisania go po raz pierwszy. Dzięki temu możemy pracować przez pełne dwie lekcje wpisując nasz access token tylko raz, kiedy zostaniemy o to poproszeni. Jeżeli natomiast wyłączę maszynę wirtualną i ktoś uruchomi ją potem, nie będzie mógł wykorzystać zapisanego tokenu, ponieważ był on zapisany w pamięci ulotnej.

Aby się upewnić, że tak jest uruchom następującą komendę i upewnij się, że zwraca ona wartość cache --timeout 5400

> git config credential.helper

Gdyby jednak się zdarzyło, że ktoś przechwycił Twój access token, pamiętaj że możesz w dowolnej chwili usunąć go w swoich ustawieniach użytkownika na platformie z której korzystasz.

Branching, współpraca z innymi, itp. w git

Git to dość skomplikowane i potężne narzędzie. Na potrzeby tych zajęć wystarczy nam to, czego się dziś nauczyliśmy.

Jeżeli chcesz się dowiedzieć więcej na temat tego, jak możesz tworzyć osobne gałęzie do pracy nad nowymi funkcjonalnościami albo jak synchronizować swoją pracę z innymi w wygodny sposób, możesz z korzystać z jednego z wielu kursów dostępnych w Internecie na temat gita.

Podsumowanie

Po dzisiejszej lekcji powinieneś potrafić: