Wprowadzenie do git z wykorzystaniem IntelliJ IDEA. Realny przypadek użycia

W tym artykule przedstawię praktyczne wykorzystanie systemu git bez konieczności znajomości konsolowych poleceń tak, aby maksymalnie wykorzystać system git oraz produktywność przy pracy z tym systemem, którą dostarcza IntelliJ IDEA z graficznym interfejsem dla git’a. Prezentowane zagadnienia będą zarówno od strony teoretycznej, jak i praktycznej. To nie jest kolejny kurs git, ale realny przypadek użycia git w dowolnym projekcie zarówno komercyjnym jak i projekcie do portfolio.

Jacek Jabłonka. Mentor, Trener – od zera do Junior Java Developer’a. Twórca i autor bloga www.juniorjavadeveloper.pl – poradnika dla przyszłych Junior Java Developer’ów. Doświadczenie umożliwia mu pomoc innym w przekwalifikowaniu się, zmianie zawodu na Junior Java Developer’a. Przez 12 lat pracował jako konsultant informatyczny, głównie w języku Java. Od września 2018 roku zajmuje się przebranżawianiem osób na Junior Java Developer’a.

Poniżej opiszę elementy związane z systemem git, każdy punkt będzie zawierał również informacje o tym jakie zastosowanie mają te polecenia dla projektu jako całości, jak również dla samego developer’a.

1. Pobranie zdalnego repozytorium – git clone.
2. Utworzenie lokalnego branch’a – git branch.
3. Umieszczenie zmian w lokalnym repozytorium – git commit.
4. Umieszczenie zmian w zdalnym repozytorium – git push.
5. Przekazanie kodu do review – Pull/Merge Request.
6. Pobranie zmian ze zdalnego repozytorium – git pull.

Na wstępie przedstawię zarys historyczny oraz garść informacji. Obecnie zespoły pracujące nad kodem aplikacji, systemu składają się z więcej niż jednej osoby i często pracują z różnych lokalizacji np. zdalnie. W takim środowisku współdzielenie kodu jest czymś naturalnym. Minęły już czasy, kiedy kod wymieniano za pomocą płyt CD lub wysyłano za pomocą wiadomości email.

Członkowie zespołu współdzielą, czyli wymieniają się kodem za pomocą systemu kontroli wersji np. git, mogą to być np.: developerzy (nowe funkcje systemu), jak również testerzy (testy automatyczne). Istnieje kilka innych systemów kontroli wersji, takich jak np.: SVN, CVS, Mercurial. Git stał się bardzo popularny, bo jest rozproszonym systemem kontroli wersji. Został napisany przez Linus’a Torvalds’a, twórcy jądra (kernel) Linux’a, czyli developer napisał narzędzie dla samego siebie.

Zanim przystąpię do omawiania punktów przedstawionych na początku artykułu, to przedstawię mój sposób pracy z git, który wypracowałem sobie przez lata pracy na stanowisku Java Developer’a.

Mój sposób pracy z git jako Java Developer

1. Rano pobranie zmian ze zdalnego repozytorium – git pull.
2. W trakcie pracy dla każdej funkcjonalności tworzę branch – git branch.
3. Przed wyjściem z pracy przesłanie zmian do zdalnego repozytorium – git push.
4. Review kodu, czyli git push w połączeniu z Pull/Merge Request.

Żeby można było korzystać z narzędzia git trzeba zainstalować odpowiednie oprogramowanie, dla Windows będzie, to git-scm.com/downloads, dla Linux git możemy zainstalować z terminala.

Dlaczego git z poziomu IntelliJ IDEA? Proszę zerknąć na poniższy zrzut ekranu i opis pod nim.

Wprowadzenie do git z użyciem IntelliJ IDEA – merge conflict

Często osoby zaczynające przygodę z programowaniem nie znają dobrze narzędzi takich jak terminal/konsola, które wymagają znajomości poleceń oraz ich parametrów wprowadzanych za pomocą tekstu (a nie na zasadzie wyklikania polecenia w okienku). Za pomocą terminala korzysta się z takiego narzędzia jak git.

Na początku system należy skonfigurować właśnie z konsoli za pomocą poleceń wpisywanych ręcznie. Brak konfiguracji git’a prowadzi do sytuacji, w której początkujący programista w terminalu widzi bliżej mu nieznany edytor tekstu bez wersji okienkowej, nie zna skrótów, a do tego jego kod wygląda jak na powyższym zrzucie ekranu. Tak wygląda kod w trakcie operacji scalania, git merge.

Z terminala za pomocą edytora tekstu należy ręcznie usunąć specjalne znaczniki git’a np.: >>>>>>> i/lub ======= oraz wybrać właściwą wersję kodu. Dla sporej części osób jest to sytuacja bez wyjścia, wtedy robią restart IntelliJ lub zamykają terminal w nadziei, że „samo zniknie”. Niestety git niczego nie zapomina (git blame), a tym bardziej nie przerwie procesu scalania kodu (git merge) po restarcie IntelliJ lub terminala.

W IntelliJ sytuacja będzie wyglądała zupełnie inaczej, kod będziemy scalać w graficznym edytorze tekstu, a każdy etap scalania kodu (git merge) będzie w formie okienek i komunikatów oraz będzie wyglądał jak na poniższych zrzutach ekranu.

Wprowadzenie do git z użyciem IntelliJ IDEA – merge conflict GUI – lista konfliktów

Wprowadzenie do git z użyciem IntelliJ IDEA – merge conflict GUI – rozwiązywanie konfliktów

Rozproszony system kontroli wersji jakim jest git umożliwia pracę nad własnym kodem lokalnie (lokalne repozytorium git) bez dostępu do internetu i do kodu innych osób. Umożliwia również pracę z kodem innych osób, czyli ze zdalnym repozytorium. W git pracujemy na gałęziach nawet na samym początku, główna gałąź lokalna, to master lub main, natomiast główna gałąź zdalna, to origin.

Przy pracy z git w IntelliJ należy wiedzieć, co oznaczają poszczególne kolory plików podczas pracy z git, polecam zapoznanie się z jetbrains.com/help/idea/file-status-highlights.html. Dodatkowo trzeba wiedzieć jaki status mają pliki w git, więcej informacji na git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository oraz na git-scm.com/docs/git-status.

Wprowadzenie do git z użyciem IntelliJ IDEA – główny branch lokalny master i zdalny origin

Oferty pracy z

Ad. 1. Pobranie zdalnego repozytorium – git clone.

TEORIA

Jeżeli już mamy narzędzia do obsługi git, to teraz musimy pobrać kod, w większości sytuacji będzie, to kod ze zdalnego repozytorium, będziemy potrzebowali URL zdalnego repozytorium np.: github.com/juniorjavadeveloper-pl/git-training-01.git. Pierwsze pobranie kodu z repozytorium nazywa się klonowaniem, polecenie git clone. Możemy tę operację wykonać z poziomu wiersza poleceń lub IDE IntelliJ IDEA. Więcej szczegółów można znaleźć naatlassian.com/git/tutorials/setting-up-a-repository/git-clone.

PRAKTYKA

Poniższe zrzuty ekranów prezentują praktyczny przykład klonowania zdalnego repozytorium z GitHub do IntelliJ.

Pobranie adresu URL repozytorium – Klonowanie repozytorium z GitHub

Utworzenie nowego projektu w IntelliJ – Klonowanie repozytorium z GitHub

Utworzenie nowego projektu w IntelliJ – Klonowanie repozytorium z GitHub

PRZYPADEK UŻYCIA

W większości przypadków będziemy korzystać z istniejącego repozytorium, dlatego tak ważny jest URL. Adres zdalnego repozytorium będziemy musieli uzyskać od kogoś, w pracy może, to być nasz przełożony lub kolega z zespołu. Jeżeli posiadamy URL repozytorium i zrobiliśmy klon repozytorium (git clone), to nie koniecznie będziemy mogli wysłać nasze zmiany (git push) na zdalną gałąź origin, będziemy potrzebowali uprawnień do takiej operacji, ktoś będzie musiał nadać nam niezbędne uprawnienia.

Ad. 2. Utworzenie lokalnego branch’a – git branch.

TEORIA

Branch, to kopia kodu, plików aplikacji, którą można równolegle rozwijać, a następnie scalić, połączyć z inną gałęzią np. master. Równoległy rozwój kodu pozwala uniknąć „omyłkowego” nadpisania, usunięcia kodu, plików oraz umożliwia powrót do właściwej wersji kodu, plików aplikacji. Więcej szczegółów można znaleźć na atlassian.com/git/tutorials/using-branches.

PRAKTYKA

Poniższe zrzuty ekranów prezentują praktyczny przykład tworzenia nowego branch w IntelliJ.

Tworzenie nowego branch’a w IntelliJ – Git -> Branches…

Tworzenie nowego branch’a w IntelliJ – Git Branches + New Branch

Tworzenie nowego branch’a w IntelliJ – New branch name:

Tworzenie nowego branch’a w IntelliJ – Git Branches in…

PRZYPADEK UŻYCIA

Tworzenie nowych, oddzielnych gałęzi, branch dla funkcjonalności np. przelewy międzynarodowe pozwala uniknąć problemów przy scalaniu naszych zmian z kodem innych członków zespołu. Pozwala również na przesłanie skończonego kodu do rewiev oraz nie blokuje naszej pracy nad innymi funkcjonalnościami w systemie np. potwierdzenia wykonania przelewu. Możemy uniknąć przesłania naszego źle działającego kodu do gałęzi produkcyjnej np. master, z której zostanie zbudowana aplikacja dostępna dla wszystkich klientów.

Ad. 3. Umieszczenie zmian w lokalnym repozytorium – git commit.

TEORIA

Commit pozwala „zapisać” bieżącą wersję kodu do lokalnego repozytorium. Pozwala, to na śledzenie zmian w plikach aplikacji w dużym uproszczeniu jest, to historia zmian plików zarządzana przez system git. Każdy commit zawiera szczegółowe informacje pozwalające zidentyfikować wprowadzone zmiany jak również informacje o osobie, która dokonała zmian (git blame). Więcej szczegółów można znaleźć na atlassian.com/git/tutorials/saving-changes/git-commit.

PRAKTYKA

[Best_Wordpress_Gallery id=”18″ gal_title=”git commit w IntelliJ”]

Pliki bez zmian, śledzone przez git – przed 'git commit’ w IntelliJ

Zmodyfikowany plik, śledzony przez git – przed 'git commit’ w IntelliJ

Dodanie nowego pliku – przed 'git commit’ w IntelliJ

Komunikat 'Add File to Git’ wybieram 'Cancel’ – przed 'git commit’ w IntelliJ

Nowy plik, nieśledzony przez git – przed 'git commit’ w IntelliJ

Dodanie pliku do git, opcja menu na pliku 'Git -> + Add’ – przed 'git commit’ w IntelliJ

Nowy plik, śledzony przez git – przed 'git commit’ w IntelliJ

Wykonanie 'git commit’, opcja menu 'Git -> Commit…’ – przed 'git commit’ w IntelliJ

Przegląd zmian w plikach + komentarz – przed 'git commit’ w IntelliJ

Przegląd zmian w systemie git w IntelliJ, polecenie 'git log’

PRZYPADEK UŻYCIA

Bardzo ważne jest robienie commitów z komentarzem (commit message). Powinien być nie za długim opisem biznesowym. Nie ma sensu umieszczać informacji o plikach, które zmieniliśmy, bo i tak będą widoczne w systemie git, tzw. git blame. Osoba przeglądająca historię zmian, commit’ów czyta komentarz, aby znaleźć interesującą ją zmianę, a dopiero potem przegląda listę plików, które zostały zmienione.

Ad. 4. Umieszczenie zmian w zdalnym repozytorium – git push.

TEORIA

Pracę z kodem w git rozpoczynamy na naszym lokalnym repozytorium. Wykonując wyżej opisany git commit umieszczamy zmiany w lokalnym repozytorium. Na pewnym etapie prac trzeba umieścić nasz kod w zdalnym repozytorium… Więcej szczegółów można znaleźć na atlassian.com/git/tutorials/syncing/git-push.

PRAKTYKA

Commit (Add new file…) bez etykiety, label 'origin’ przed 'git push’ – IntelliJ

Przygotowanie push, opcja menu 'Git -> Push…’ – IntelliJ

Lista commit’ow do wysłania, push do zdalnego repozytorium – IntelliJ

Commit z etykieta, label 'origin’ jest w zdalnym repozytorium – IntelliJ

PRZYPADEK UŻYCIA

Na koniec dnia przesyłamy nasz kod do zdalnego repozytorium pozwoli, to uniknąć sytuacji, w której z przyczyn losowych np.: awaria komputera, choroba, nie będziemy w stanie kontynuować pracy. Kiedy kod jest w zdalnym repozytorium, to w łatwy sposób można kontynuować pracę z nim.

Ad. 5. Przekazanie kodu do review – Pull/Merge Request.

TEORIA

Pull Request lub Merge Request jest niezależne od systemu git, zostało stworzone przez platformy wspierające proces wytwarzania oprogramowania, które korzystają z systemu git, oferowane przez np. GitHub, GitLab, Bitbucket. Dodają one dodatkowe funkcje i możliwości do systemu git, które są wykorzystywane w trakcie procesu wytwarzania oprogramowania. Technicznie „na końcu” Pull Request wykonywane jest polecenie git merge.

Więcej szczegółów można znaleźć na:

• docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests – dla GitHub,
• docs.gitlab.com/ee/user/project/merge_requests/getting_started.html – dla GitLab,
• support.atlassian.com/bitbucket-cloud/docs/tutorial-learn-about-bitbucket-pull-requests – dla Bitbucket.

PRAKTYKA

[Best_Wordpress_Gallery id=”20″ gal_title=”Pull Request na GitHub”]

Zakładka 'Pull requests’, repozytorium git – GitHub

Tworzenie 'Pull request’, wybór branch’y do 'git merge’, brancz docelowy i źródłowy – GitHub

Podgląd różnic w kodzie, które będą scalane w ramach 'Pull request’ + utworzenie 'Create pull request’ – GitHub

Wybór osoby, która wykona przegląd kodu 'Reviewers’ + zatwierdzenie 'Create pull request’ – GitHub

Podgląd utworzonego 'Pull request’ – GitHub

Zatwierdzanie przejrzanego 'Pull request’, przycisk 'Confirm merge’ – GitHub

Usunięcie zakończonego 'Pull request’, przycisk 'Delete branch’ – GitHub

PRZYPADEK UŻYCIA

Ostatnim ważnym elementem w pracy z git i kodem źródłowym jest przesłanie kodu do review. Sam git nie posiada opcji Pull/Merge request, są to dodatki do takich serwisów jak GitHub.com, GitLab.com lub Bitbucket.org. Dlaczego code review jest tak ważny? Kod, który piszemy dla nas samych jest idealny, ale warto, aby przejrzały go osoby bardziej doświadczone w naszym zespole. Dodatkowo osoby, które będą bezpośrednio korzystały z naszego kodu np.: poprzez API, będą miały możliwość zapoznania się z API i/lub zgłoszenia zmian, które pozwolą na poprawne połączenie np.: dwóch modułów systemu.

Ad. 6. Pobranie zmian ze zdalnego repozytorium – git pull.

TEORIA

Pull pozwala pobrać zmiany w kodzie umieszczone w zdalnym repozytorium przez innych członków zespołu pracujących przy tej samej aplikacji. Za pomocą git pull możemy również pobrać nasze własne zmiany scalone po wykonaniu Pull/Merge Request. Polecenie git pull pobiera zmiany i jednocześnie scala git merge nasze zmiany w lokalnym repozytorium z tymi pobieranymi ze zdalnego repozytorium. Więcej szczegółów można znaleźć na atlassian.com/git/tutorials/syncing/git-pull.

PRAKTYKA

Status repozytorium git przed wykonaniem 'git pull’ – IntelliJ

Przygotowanie do pobrania zmian ze zdalnego repozytorium, opcja menu 'Git -> Pull…’ – IntelliJ

Wybór 'branch’ do pobrania zmian ze zdalnego repozytorium – IntelliJ

Status repozytorium git po wykonaniu 'git pull’, pobrane zmiany – IntelliJ

PRZYPADEK UŻYCIA

Zawsze powtarzam, że przy pracy z git najważniejsza jest poranna kawa, a potem git pull, czyli pobranie zmian ze zdalnego repozytorium. Dlaczego tak ważna jest kawa? Po zrobieniu git pull możemy spodziewać się konfliktów w naszym kodzie. Pracując w międzynarodowym zespole, nasi serdeczni koledzy/koleżanki zza granicy, kiedy my spaliśmy mogli dodać zmiany do głównej gałęzi, a zależy nam na tym, żeby zawsze mieć aktualną główną gałąź main/master. Dla aktualnej wersji gałęzi głównej będziemy mogli zrobić nasze własne branch’e z nowymi funkcjonalnościami.

Podsumowując git jest niezbędny do pracy każdego programisty. Początkujący mają trudności z opanowaniem systemu git z terminala/konsoli dlatego zalecam stosowanie narzędzi dostępnych w IntelliJ IDEA, które dostarczają niezbędne wsparcie dla początkujących programistów. Należy pamiętać, że git, to nie tylko wersjonowanie kodu, ale również cały proces wsparcia wytwarzania oprogramowania za pomocą np. git branch, Pull/Merge Request.

Zapraszam do regularnego odwiedzania mojej strony, będą pojawiać się kolejne artykuły oraz do kontaktu przez email kontakt(at)juniorjavadeveloper.pl. Aktualna oferta dostępna na juniorjavadeveloper.pl/oferta/.

Zdjęcie główne artykułu pochodzi z unsplash.com.