No i GIT! … ale o co chodzi?

Uczestnicy kursów programowania i warsztatów programistycznych poznają istniejące systemy kontroli wersji kodu i uczą się korzystać z Git’a. Niemal wszyscy z tych, których miałem okazję poznać jako instruktor, przy pierwszym kontakcie z linią komend Git’a zdają się być przytłoczeni mnogością nowych komend do nauczenia i związaną z nimi nową formą organizacją pracy z kodem. Nie mówiąc już o frustracji przy pojawiających się raz po raz konfliktach, problemach ze znikającymi plikach na lokalnych komputerach czy próbie wysyłania do centralnego repozytorium pustych commit’ów. Na szczęście przewaga stacjonarnego kursu programowania nad innymi dostępnymi formami, to przede wszystkim obecność instruktora, który jest w stanie bezpośrednio, w zrozumiały sposób wytłumaczyć wszystkie niejasności i pomoże przełamać barierę strachu przed korzystania z nowego narzędziem. Co jednak jeśli ktoś nie robi notatek i po powrocie do domu poczuje, że jednak wciąż nie czuje się na tyle pewnie, żeby kolejne zadania domowe robić z GIT’em? Na pomoc przygotowałem Wam poniższy wpis. Przedstawię w nim sens stosowania systemów kontroli wersji, podstawowy workflow (czyli organizację pracy 🙂 ) i rozwiązania najczęstszych problemów. Pokażę Ci również, jak pracować z GitHub i na czym polega różnica między Git’em i Git’hubem. Wyjaśnijmy sobie w końcu, o co chodzi z tym Git’em!

Systemy kontroli wersji? O co chodzi?

Nie można mówić o wydajnej pracy z kodem w projekcie programistycznymi, czy nawet samodzielnej pracy na kursie programowania, bez użycia jakiegokolwiek systemu kontroli wersji. Czy to znaczy, że istnieje takich systemów więcej? Tak. Najbardziej popularny GIT, jest tylko jedną z możliwości.

Systemy kontroli wersji (VCS od Version Control Systems) to narzędzia, których zadaniem jest śledzenie zmian we wskazanych przez programistę plikach. Dzięki temu automatycznie powstaje historia dokonanych zmian i kolejnych wersji projektu. Gdyby nie VCS’y to każdy zmieniony plik należałoby wysłać do pozostałych członków zespołu, aby każdy pracował z najbardziej aktualnym kodem. Scenariusz ten jest, z wiadomych względów, niemożliwy do zrealizowania. Nawet w przypadku samodzielnej pracy należy liczyć się z tym, że w pewnym momencie możemy skończyć z wieloma wersjami jednego pliku, tylko dlatego że w trakcie dodawania nowych funkcjonalności, z obawy przed popsuciem aplikacji, nie chcieliśmy pracować bezpośrednio na działającym kodzie.

Istnieją trzy typy systemów kontroli wersji:

1. Lokalny system kontroli wersji
2. Centralny system kontroli wersji
3. Rozproszony system kontroli wersji

W tym wpisie chciałbym zająć się tylko rozproszonym system wersji, na przykładzie GIT’a. Jego siła tkwi w tym, że kod na komputerze każdego członka zespołu stanowi idealną kopię całego repozytorium (czyli historii projektu wraz ze wszystkimi wersjami plików; repozytorium jest tworzone wraz z inicjalizacją GIT’a w projekcie). Oznacza to, że każdy ma dostęp do najnowszych, udostępnionych plików i całej historii wykonanych zmian. Jest to świetna sprawa, ponieważ w przypadku uszkodzenia serwera centralnego (np. GihHub) można bez problemu odtworzyć cały dotychczasowy projekt. Dzięki temu, że cała dotychczasowa historia znajduje się bezpośrednio na dysku i nie jest konieczne odpytywanie żadnego zewnętrznego serwera, wszystkie operacje wykonywane przez GIT’a są bardzo szybkie i można z niego korzystać bez dostępu do internetu. Jest to na pewno duże ułatwienie dla osób dojeżdżających na zajęcia w ramach naszego kursu programowania pociągami, aby w drodze zrobić zaległe zadania domowe! Argument, że nie było w PKP zasięgu i nie udało się zapisać wszystkich zmian traci na mocy 😉

Instalacja programu

---

Przygotowanie GIT’a do pracy

Po zainstalowaniu niezbędnego oprogramowania, należy je przygotować do pracy z własnymi repozytoriami. Przeważnie taka konfiguracja odbywa się tylko raz i polega na ustawieniu odpowiednich wartości dla zmiennych konfiguracyjnych nazwy użytkownika i adresu e-mail.

Do ich ustawienia stosuje się metodę git config. Poniżej przykład zastosowania:
git config --global user.name "[twoja nazwa użytkownika]"
git config --global user.email "[twoj adres email]"

Użycie flagi --global spowoduje, że informacje do pliku .gitconfig w głównym (nazywanym też domowym) folderze użytkownika i będą dostępne dla wszystkich aktualnych i przyszłych projektów GIT.

Praca z repozytorium

Mając już zainstalowany i skonfigurowany system kontroli wersji, jesteśmy w stanie zacząć pracę z repozytorium. Na utworzenie projektu (lub też inaczej na utworzenie repozytorium na lokalnym komputerze) istnieją dwie metody. Należy znać oba, ponieważ oba mają swoje zastosowania zarówno przy samodzielnej nauce programowania, jak i na kursie z gotowymi przykładami.

Metoda 1: Utworzenie projektu lokalnie, a następnie wyeksportowanie go do GitHub’a.

W kontekście naszych kursów, to rozwiązanie należy stosować, gdy już utworzyliście projekt i rozpoczęliście już pracę nad konkretnymi zadaniami na własnym komputerze.

Przede wszystkim trzeba pamiętać, że GIT i GitHub to dwie różne rzeczy. Git to system kontroli wersji. GitHub to aplikacja umożliwiająca przechowywanie repozytoriów GIT na osobnym serwerze, ułatwiając tym samym pracę zespołową w projekcie, udostępniając dostęp do repozytorium każdemu członkowi. Istnieją alternatywy dla GitHub’a, jednak ze względu na jego popularność i wygodę w użyciu większość osób decyduje się właśnie na niego przy wyborze aplikacji, umożliwiającej przechowywanie repozytoriów na zewnętrznych serwerach.

(opcjonalne) Utworzenie konta GitHub

Jeśli jeszcze nie posiadasz konta na GitHub, należy najpierw przejść proces rejestracji. Jest bardzo prosty i wymaga jedynie wypełnienia prostego formularza oraz wybrania odpowiedniego planu cenowego. Wybieramy plan darmowy. Strona z rejestracją znajduje się pod adresem https://github.com/join .

---

---

Pierwszy commit

---

---

---

---

W tym kroku to już prawie wszystko! Zainicjowaliśmy repozytorium, wykonaliśmy pierwszy commit. Ale repozytorium cały czas znajduje się tylko na dysku komputera. Aby poczuć pełną moc oferowaną przez GIT’a, zmiany należy upublicznić i przećwiczyć pracę z zewnętrznym serwerem (tzw. remote).

Utworzenie remote’a polega oznacza utworzenie połączenia z innym repozytorium. Sam remote (ang. zdalne) to po prostu repozytorium, które nie znajduje się na lokalnym komputerze. Takie repozytorium może być przechowywane na osobnym serwerze (np. na GitHub), tak aby każdy członek projektu miał do niego dostęp. To z tego adresu inni użytkownicy będą mogli sklonować nasz projekt.

Przygotujmy zatem lokalne repozytorium do pracy z GitHub’em. Przygotowanie będzie polegać na wskazaniu zewnętrznego URL, do którego będą wysyłane wszystkie zmiany wykonane lokalnie. W tym celu stosuje się komendę, ustawiającą nam tzw. remote’a:
git remote add origin "link repozytorium na GitHub".

---

---

---

W ten sposób udało nam się zrealizować jeden z dwóch podstawowych sposobów tworzenia repozytorium GIT i integrowania go z GitHub’em. Polegał on na utworzenia repozytorium na podstawie plików na lokalnym komputerze i wysłania ich do GitHub. Podsumujmy szybko ten proces i przypomnijmy użyte komendy:

1. Inicjacja pustego repozytorium w folderze projektowym, na lokalnym komputerze za pomocą komendy git init . (Komenda ta jest wywoływana tylko 1 raz dla każdego repozytorium!)
2. Poinformowanie GIT’a, o tym, które pliki z dysku mają się znaleźć w repozytorium. Jeśli chcemy, aby wszystkie pliki zostały dodane używamy komendy git add . .
3. Wykonanie pierwszego commita przy użyciu komendy git commit -m "[tytuł commita]".
4. Dodaliśmy tzw. remote’a, czyli wskazaliśmy adres, pod którym projekt jest przechowywany na GitHub i skąd inni członkowie projektu mogą go pobrać. W tym celu zastosowaliśmy metodę
   git remote add origin https://github.com/01float/ZadaniaAngularNodeJS.git (Komenda ta jest wywoływana tylko 1 raz dla każdego repozytorium!)
5. Na sam koniec wszystkie scommitowane zmiany zostały wypchnięte (lub też spushowane, upublicznione). Czyli zostały wysłane na wskazany przed chwilą adres. W tym celu została użyta komenda
   git push --set-upstream origin master .
   
   Flaga --set-upstream origin master jest używana tylko przy pierwszej próbie pushowania (wypychania, upubliczniania) zmian. Służy ona do tego, aby poinformować lokalne repozytorium, z którym zewnętrznym branchem chcemy się zscynchronizować i śledzić zmiany.
   
   

---

W międzyczasie też skonfigurowaliśmy też GIT’a i przygotowaliśmy projekt z GitHubem. W tym celu:

• Skonfigurowaliśmy nazwę użytkownika i jego email, dzięki czemu te dane będą widoczne dla pozostałych członków projektu. W tym celu zostały użyte komendy:
  git config --global user.name "[twoja nazwa użytkownika]"
git config --global user.email "[twoj adres email]"

---

Metoda 2: Przygotowanie środowiska do pracy poprzez sklonowanie projektu z już istniejącego z zewnętrznego repozytorium

Zobaczmy teraz, jak przygotować się do pracy z repozytorium utworzonym przez kogoś innego i udostępnionego na GitHub. Poniższa instrukcja będzie również się nadawać do projektu umieszczonych w innych serwisach (np. GitLab).

Instrukcja wykorzystywana do pracy z przygotowanymi przykładami i zadaniami od instruktora. Kod znajduje się w repozytorium na GitHub. Korzystając z lokalnej instalacji GIT’a jest on pobrany ze wskazanego adresu. W ten sposób zostaną pobrane cała historia o wykonanych zmian oraz branche.

W tym scenariuszu musimy znać adres projektu, który chcemy sklonować. W ramach tego przykładu, polecam użycie repozytorium zawierające kod szablonu WordPress, przygotowanego w osobnym tutorialu.

Projekt jest dostępny pod adresem https://github.com/01float/l2c-wordpress-basic-theme .

Zwróć uwagę, że przykładowy projekt jest skonfigurowany jako publiczny. Oznacza to, że jest dostępny do sklonowania dla wszystkich. Istnieją również projekty prywatne. W ich przypadku, aby móc z nimi pracować, należy najpierw otrzymać dostęp od osoby administrującej projektem.

Aby znaleźć link repozytorium do pobrania, należy kliknąć przycisk code, a następnie skopiować wyświetlony adres.

To wszystko! Nic więcej nie jest potrzebne, aby sklonować repozytorium i na jego podstawie rozpocząć pracę nad powierzonymi zadaniami. Można śmiało tworzyć nowe branche, pushować zmiany do repo na remote czy mergować branche innych kursantów w pracy nad projektem grupowym 🙂

UWAGA! W ten sposób skopiowaliśmy cały projekt (a konkretniej repozytorium), na komputer. Żeby móc pracować z projektem (czyli commitować i pushować) zmiany, należy upewnić się, że mamy skonfigurowane GIT’a, czyli czy mamy chociażby ustawiony adres email, użytkownika. Wskazówki jak to zrobić, znajdziesz w sekcji Przygotowanie GIT’a do pracy 🙂

Jak pracować z GIT’em?

GIT jako system kontroli wersji służy do śledzenia zmian wykonanych przez użytkownika na jego lokalnych plikach oraz upubliczniania tych zmian pozostałym członkom zespołu. Choć w tym momencie wydaje się to oczywiste, chciałem przypomnieć rolę jako on odgrywa, ponieważ dzięki temu łatwiej będzie nam zrozumieć proponowany tryb pracy, stosowany przy każdym projekcie (tym sklonowanym również!). Wygląda on w sposób następujący:

---

---

Te 4 kroki przedstawiają najprostszy możliwy scenariusz pracy z GIT’em. Jak widać jest on identyczny dla repozytoriów utworzonych lokalnie oraz sklonowany. Przypominając raz jeszcze (w ramach utrwalenia), wyglądają one tak:

1. Wykonaj zmianę w jednym lub wielu plikach. Usuwanie i dodawanie nowych plików również zalicza się jako zmiana, bo zmienia się “stan” projektu!
2. Poinformuj GIT o tym, że chcesz, aby uwzględnił zmiany w plikach, na których pracujesz w kolejnym commicie. Do tego celu służy komenda git add .
3. Po upewnieniu się, że wszystkie pliki, na których ci zależy są śledzone (w sekcji tracked, komendy git status) scommituj je komendą git commit -m “tytul commita”
4. Upublicznij zmiany korzystając z komendu git push.

Jak sobie radzić z niechcianymi zmianami?

Jeden z najczęstszych problemów, z którym borykają się uczestnicy kursów programowania, dotyczą wycofywania wprowadzonych zmian. Scenariuszy, w których się pojawia jest na kilka.

• Uczestnik kursu po ostatnim działającym commicie przebudował całą strukturę komponentów w swojej aplikacji. Zmiany zostały wykonane w wielu plikach i ręczne ich wycofywanie będzie bardzo czasochłonne. Uczestnik chciałby jednak, aby kod jego aplikacji był taki sam jak w commicie przed zmianami, żeby mieć punkt odniesienia do dalszej pracy.
• Podczas pracy w projekcie grupowym, uczestnik całkowicie przebudował jeden z głównych serwisów aplikacji i po spushowaniu zmian, okazało się, że niektóre komponenty nie działają poprawnie. Ręczne wycofywanie linijka, po linijce znowu nie wchodzi w grę.
• Uczestnik kursu chciał napisać od początku kod stylów w jednym z komponentów. Nie jest jednak zadowolony z rezultatu i nie chciałby, aby znalazły się w następnym commicie.

Na szczęście GIT dostarcza nam szereg prostych rozwiązań dla powyższe problemy. Wybór odpowiedniego zależy od tego, czy zmiany zostały już scommitowane czy jeszcze nie oraz czy zostały juz spushowane.

Zmiany nie zostały jeszcze scommitowane

Jest to przypadek 3 z powyższej listy. Sugeruję, aby w pierwszej kolejności uruchomić komendę git status. Dzięki temu zobaczysz wszystkie pliki, w których doszło w jakikolwiek sposób do zmiany. Komenda ta również podpowiada rozwiązanie dla tego przypadku:

 use git checkout -- .. to discard changes in …

Zatem aby cofnąć zmiany w jednym pliku, wystarczy użyć komendy:
git checkout -- [nazwa pliku]

Jeśli chcemy cofnąć zmiany we wszystkich plikach, należy użyć komendy
git checkout -- .
(kropka oznacza wszystkie pliki, w aktualnym projekcie) . Alternatywą dla tej komendy jest
git reset --hard ,
która wyczyści wszystkie zmiany i cofnie pliki do stanu z poprzedniego commita. Jest to szybkie i skuteczne rozwiązanie, które z precyzją bomby atomowej cofnie wszystkie zmiany, dlatego należy go używać z rozwagą!

Przykład zastosowania

---

---

Zmiany zostały już dodane i scommitowane

Co jeśli zmiany już zostały scommitowane? A jeśli już zostały wysłane innym? W tym wypadku rozwiązanie nie jest aż tak trywialne. Sposobem w jaki Git sobie poradzi jest przygotowanie nowe commita, w którym cofnie wszystkie zmiany ze wskazanego, innego commita.

---

---

Jest to zalecane rozwiązanie, przede wszystkim w pracy grupowej. Jego zaletą jest to, że nie zmienia historii wykonanych zmian w GIT’cie. Oznacza to, że nie znikną z niej żadne informacje. Wciąż będzie widoczny commit z niechcianymi zmianami, ale też commit je cofający oznaczony jako revert. Nie będzie to miało wpływu na aktualny stan kodu, a zaoszczędzi problemów innym programistom czy kursantom.

Co to znaczy “być na właściwym branchu”?

Największą zaletą stosowania kontroli wersji jest możliwość pracy na różnych branchach (czyt. gałęziach). Wyobraź sobie, że chcesz zacząć pracę nad nową funkcjonalnością. Ze względu na stopień skomplikowania zadania, zmiany trzeba będzie wprowadzić w wielu plikach, w tym w tych kluczowych, stanowiących trzon całej aplikacji. Już wiesz, że istnieją sposoby na cofanie ewentualnych zmian, ale mimo wszystko nie chcesz ryzykować pracy na kodzie źródłowym, z którego korzystają też inni oraz obawiasz się, że w międzyczasie pojawi się z ich strony również dużo zmian i trudno będzie je połączyć. Pojawia się problem.

Rozwiązaniem tego problemu byłaby możliwość równoległej pracy na kopii głównego kodu źródłowego, a dopiero po zakończeniu prac ich połączenie. Do tego właśnie służą branche. W projekcie istnieje zawsze jeden główny branch (nazywany np. master, main). Programista może w dowolnym momencie stworzyć nową gałąź, czyli nowego brancha, wychodzącą od brancha głównego. To tak jakby mówił “ja teraz biorę cały kod do siebie i będę pracował na mojej gałęzi, którą nazwę nowa-funkcjonalność”. Dzięki temu może dodawać nowe funkcjonalności bez przypadkowego naruszania kodu bazowego.

Do realizacji powyższego scenariusza potrzebne będą dwie komendy:

1. git branch nazwa_brancha – dzieki której zostanie utworzony nowy, lokalny branch
2. git checkout nazwa_brancha – aby przejść z aktualnego brancha, na nowy przed chwilą utworzony

Można też użyć
git checkout -b nazwa_brancha ,
która łączy dwie powyższe (tworzy nowy branch i od razu na niego przechodzi).

Może też się zdarzyć tak, że zdecydowałeś lub zdecydowałaś się pracować bezpośrednio na branchu głównym (najczęściej master lub main), ponieważ wydawało się, że dodanie nowej funkcjonalności to będzie tylko parę linijek kodu. Prace nad nowym kodem trwają w najlepsze, a z pozoru niewielka zmiana liczy już kilkadziesiąt linijek i pojawiają się obawy o poprawność implementacji. Na całe szczęście poznane przed chwilą komendy pozwolą Ci wybrnąć z tej sytuacji.

Jeśli zostaną dokonane zmiany na branchu głównym (master), to wywołanie komendy
git checkout -b nowy_branch
spowoduje, że wraz ze wszystkimi (nie scommitowanymi!) wykonanymi do tej pory zmianami przeniesiemy się na nowy branch, pozostawiając branch główny czysty.

Na poniższym przykładzie widać jak należy to zrobić:

• Będąc na branchu master, utworzyłem nowy branch o nawie contact-form. Użyłem w tym celu komendy
  git branch contact-form
• Wszedłem na nowy, przed chwilą utworzony branch za pomocą komendy
  git checkout contact-form
• Poprzez użycie komendy git status, upewniłem się, że jestem na odpowiednim branchu.

U mnie działa! Co dalej?

Gdy praca na twoim branchu dobiegła końca, musisz dodać nowe zmiany do brancha głównego (mastera). Dzięki temu pozostali członkowie projektu będą mogli je pobrać oraz znajdą się one w historii projektu. Zanim pokażę jak to zrobić, należy tutaj podkreślić bardzo ważną, acz może oczywistą rzecz. Na swoich lokalnych branchach należy pracować zgodnie z trybem pracy GIT’a.

Po zakończeniu pracy, dodajemy pliki projektowe komendą git add ..

Następnie je commitujemy komendą git commit -m "tytuł commita".

Zdarza się, że kursanci o tym zapominają. Wykonanie commita jest konieczne, aby GIT zapamiętał nasze zmiany. Bez tego, po połączeniu z branchem głównym okażę się, że nie została dodana ani jedna linijka kodu! Dlatego najpierw zawsze upewnij się, że wszystkie zmiany na twoim branchu zostały scommitowane. Można to zrobić stosując komendę git log, wyświetlający listę ostatnich commitów. Jeśli odnajdujesz na niej wszystkie dotyczące bieżących zadań, to znaczy, że lokalna historia jest aktualna.

Następnie można przejść do połączenia brancha głównego z twoim. Są na to dwa sposoby: merge i rebase. Teraz pokażę Ci tylko haj używać merge’a. Jest to metoda w pełni wystarczająca do pracy projektowej w ramach kursu i pomoże Ci oswoić się z GIT’em.

Podsumowanie

Powyższe wprowadzenie w pełni wyczerpuje teorie potrzebną do pracy z zadaniami domowymi na kursie programowania. Zarówno na podstawie przykładów dostarczonych przez instruktora, jak i przy samodzielnie realizowanych zadaniach.

Zrealizowaliśmy w nim podstawowe scenariusze pracy z Git’em i GitHub’em. Stworziliśmy i sklonowaliśmy repozytorium oraz wykonaliśmy pierwsze merge. Do pracy projektowej potrzeba będzie jeszcze umiejętność radzenia sobie z konfliktami. Bez obaw. Tym tematem zajmę się w kolejnym wpisie 🙂