Git - poradnik dla zielonych cz.1

Poruszone zagadnienia

GitHub

Repozytorium

Branch

Commit

Szalenie istotny temat

Jeśli planujesz swoją karierę jako programista i uważasz, że temat Gita będzie można jakoś ominąć szerokim łukiem, to najlepiej będzie sobie w ogóle odpuścić ten cały projekt, aby nie tracić czasu. Dlaczego?

A to dlatego, że bez Gita ani rusz. Ani rusz, bo cały świat programowania łączą z Gitem specyficzne i nierozerwalne więzi. Jeśli nie zaprzyjaźnisz sie z Gitem, to nie licz też na przyjaźń z innymi programistami 😛 Jeśli planujesz bawić się w kodowanie, to musisz ten temat wykuć na blachę.

W mojej krótkiej karierze ucznia Javy miałem możliwość zapoznania się różnymi tematami. Randkowałem kolejno ze zmiennymi, metodami, klasami i pojęciem programowania obiektowego. Następnie wziąłem się za instrukcje sterujace oraz pętle. Potem przyszedł czas na tablice, listy oraz kolekcje. Przerobiłem troche zadań, łatwiejszych i trudniejszych. I powiem szczerze, wszystko było super. Aż do momentu kiedy pojawił się Git… I nie wiem czym to jest spowodowane, ale wśród wszystkich tych wspomnianych kwestii, to właśnie ogarnięcie Gita stało się dla mnie jakąś żelazną barierą, której początkowo nie mogłem przezwycieżyć. Temat wydawał mi się tak chaotyczny i pogmatwany, że odechciewało mi się siadać kolejnego dnia do komputera. Aż do tego momentu. Chwili, w której postanowiłem uporządkować wiedzę tworząc ten wpis. Wszystko nagle zaczęło mieć sens. To kolejne potwierdzenie i dowód na to, że praca na tym blogu ma głębszy sens. Jeśli też masz problemy z Gitem, mam nadzieję, że ten wpis i Tobie pomoże rozwiać niektóre wątpliwości.

Repozytorium

Co znaczy to magiczne słowo?

Repozytorium, czyli tzw. repo to po prostu nic innego jak miejsce do przechowywania Twojego kodu lub plików, nad którym aktualnie pracujesz. Repozytorium jest zazwyczaj zarządzane przez systemy kontroli wersji, takie jak chociażby sławetny Git. Repo może być hostowane na platformach takich jak GitHub, czy też GitLab.

Repozytorium może być publiczne lub prywatne:

public repository - dostępne dla wszystkich i może być używane do udostępniania Twojego kodu źródłowego (open source)

private repository - ograniczone dostępem, co oznacza, że tylko uprawnione osoby mają dostęp do jego zawartości

Repozytorium może być również wewnętrzne i zewnętrze. O tym opowiemy sobie zaraz.

Git - system kontroli wersji

Git to po prostu rozproszony system kontroli wersji. Tak, wiem. Też nic mi to nie mówiło 😁 Po kolei…

Git umożliwia śledzenie zmian w kodzie źródłowym podczas rozwoju oprogramowania. Pozwala różnym programistom współpracować nad projektem, zapewniając mechanizmy do zarządzania i scalania zmian w kodzie. Git zapewnia elastyczność, skuteczność i szybkość w zarządzaniu kodem, umożliwiając programistom pracę niezależnie na różnych gałęziach, a następnie scalanie zmian w jedną wspólną wersję.

Struktura Gita:

Working Directory (Katalog roboczy) - to lokalny folder na Twoim komputerze, który zawiera kopię projektu Git. W tym katalogu znajdują się dane, nad którymi pracujesz. Wszystkie zmiany, które dokonujesz, takie jak dodawanie, usuwanie lub modyfikowanie plików, odbywają się w właśnie w Working Directory. To Twoja piaskowanica, w której trzymasz swoje zabawki.

Staging Area (Obszar przygotowawczy) - to pośredni obszar pomiędzy Working Directory, a następnym obszarem, którym jest Repository. Taki sektor buforowy, w którym zatwierdzasz wszystkie dokonywane przez Ciebie zmiany w danych (commit) i przygotoujesz je do tzw,. wypchnięcia (push) do Repository

Repository (Repozytorium) - inaczej repo, to miejsce, w którym Git przechowuje wszystkie wersje danych, historię zmian oraz informacje o gałęziach (branchach) i commitach. Może istnieć w formie lokalnego repozytorium na Twoim komputerze lub zdalnego repozytorium na serwerze, np. GitHubie. Repo pomaga Ci śledzić i zarządzać całym projektem oraz współpracować z innymi programistami w systemie Git

W dużym skrócie:

Repozytorium wewnętrzne - znajduje się wewnątrz, na Twoim komputerze

Repozytorium zewnętrzne - poza Twoim komputerem, np. na platformach takich jak GitHub.

Working Directory to katalog, gdzie dokonujesz zmian w plikach.

Staging Area to pośredni obszar, gdzie wybierasz zmiany zatwierdzania

Repository to miejsce, gdzie Git przechowuje pełną historię projektu

GitHub

GitHub to internetowa platforma do zarządzania kodem, która umożliwia programistom przechowywać oraz udostępniać dane, a także współpracować nad rozwojem oprogramowania

Platforma udostępnia wiele funkcji, które są bardzo przydatne w pracy nad kodem:

pozwala na kontrolę wersji kodu

umożliwiaja śledzenie zmian podczas pracy

ułatwia wprowadzanie poprawek

czyni współpracę zespołową bardziej wydajną

GitHub zapewnia również narzędzia do zarządzania zgłoszeniami błędów i integracji z innymi narzędziami programistycznymi, np. InteliJ IDEA. GitHub działa na zasadzie repozytoriów, gdzie każdy projekt ma swoje miejsce do przechowywania danych.

Jest też coś takiego jak GitHub Copilot, czyli narzędzie oparte sztucznej inteligencji ułatwiające programistom pracę, ale to już temat na osobny wpis, do którego mi jeszcze daleeeeeeko…

Branch

Jeśli spytasz mnie jak wyobrażam sobie w głowie Gita i jego elementy, to porównałbym to do solidnego, starego dębu. Tak, do drzewa. I tak się właśnie składa, że tematem tego akapitu będzie branch, czyli po ang. gałąź.

W dużym skrócie, jeśli pracujesz nad kodem zapewne masz swoją fundamentalną wersję aplikacji. W tej wersji wprowadzamy pewne usprawnienia, modyfikujemy kod, dodajemy elementy, testujemy. Jedym słowem rozwijamy nasz program.

Teraz wyobraź sobie następującą sytuację. Jak to zapewne często bywa, nagle pojawia Ci się w głowie rewolucyjny pomysł, który może usprawnić działanie Twojej apki! Lecisz do kompa, poprawiasz kod i … BACH!

Coś się wysypało i kod się nie kompiluje. Co teraz? Jeśli to tylko kilka linijek do napraawy to luzz. Wprowadzasz korektę, wracasz do punktu wyjścia i po problemie. Gorzej jeśli tak zmodyfikowałeś swój kod, że wykrzaczenie jest przepotężne, a powrócenie do stanu przed awarią zajmie Ci grube godziny.

I tutaj na białym koniu wjeżdza branch.

Branch w systemie kontroli wersji to odgałęzienie od głównej wersji kodu (zazwyczaj od gałęzi głównego o nazwie "master" lub "main"), które umożliwia niezależną i równoległą prace nad funkcjonalnością programu. To miejsce, w którym możesz sobie poekperymentować bez obawy, że Twoje igraszki skończą się totalnym wykrzaczeniem kodu.

Mamy zatem fundament drzewa, pień (master), od którego odchodzą poszczególne gałęzie, na których wprowadzamy nowe rozwiazania, bez obawy, że starcimy to nad czym długo pracowaliśmy. Jeśli przetestujemy funkcjonalość i wszystko będzie działać jak należy, wtedy łączymy gałąź z pniem i wprowadzamy nowe usprawnienie do kodu głównego. Taki transfer danych to tzw. merge.

Git w praktyce

Ok, dość gadania. Czas na trochę praktyki. Pisząc ten artykuł zakładam, że masz już zainstalowanego Gita oraz posiadasz konto na GitHubie. Jeśli nie, poniżej znajdziesz zakładkę z kotkiem, gdzie znajdziesz info jak to wszystko zrobić.

🐱

Instalacja Gita

Jeśli zainstalowałeś Gita i założyłem konto na GitHubie to zaczynamy!

💥Kliknij i wybierz interesujący Cię scenariusz:

1️⃣

Instrukcja nr 1 (wewnętrzne repo)

Dane z kompa wyślemy na GitHuba:

stworzymy na Twoim komputerze repozytorium wewnętrzne

wprowadzimy w nim kilka zmian

wykonamy push zaktualizowanych danych na GitHuba

2️⃣

Instrukcja nr 2 (zewnętrzne repo)

Dane z GitHuba pobierzemy na kompa:

stworzymy repozytorium zewnętrzne na GitHubie

wyślemy dane z GitHuba na Twój komputer

wprowadzimy kilka zmian w danych

wykonamy także tzw. pull danych na Twój komuter

3️⃣

Instrukcja nr 3 (nowe branche)

Tutaj zalecam Ci wcześniejsze zapoznanie się z Instrukcja nr 1 oraz Instrukcja nr 2. W tej sekcji:

stworzymy kilka nowych branchów

wykonamy transfer danych pomiędzy nimi (megre)

wypchamy aktualne dane na GitHuba

usuniemy niepotrzebne branche

Lista komend

1. Komendy dotyczące repozytorium wewnętrznego (Twój komputer):

git config --global

konfiguracja Gita przy pomocy nazwy użytkownika i adresu email z Githuba

git config --global user.name “jakubXXX”
git config --global user.email jakubXXX@poczta.onet.pl

konfiguracja błedu LF/ CRLF

git config --global core.autocrlf true

git init - tworzy nowe repozytorium w katalogu (m.in. ukryty pliku .git)

git status - pokazuje status repozytorium (np. czy mamy jeszcze nieśledzone pliki untrucked)

touch nazwaPliku - tworzy nowy plik (np. touch plikTekstowy.txt)

git add nazwaPliku - dodaje pliki do Staging Area (Git śledzi plik)

git add -A (dodaje do Stagingu wszystkie pliki z folderu, w którym się aktualnie znajdujemy)
korzystanie z IDE, np. z Intelij - nie używamy git add, gdyż służy do tego konkretna wtyczka

git commit -m ”Komentarz do commitu” - commitowanie, czyli zatwierdzenie zmian oraz ich dokumentacja (-m to skrót od massage)

git commit -am “Komentarz do commitu” - połączenie komend git add oraz git commit -m, bardzo użyteczna opcja (-am to skrót od add massage)

git log - pokazuje wszystkie dotychasowo dokonane commity w konsoli Basha (klinkij Q - aby wyjść z okna)

git branch - pokazuje wszyskie branche w naszym repo (branch, w którym aktualnie się znajdujemy oznaczony gwiazdką)

git branch nazwaBrancha - tworzy nowy branch

git branch -d nazwaBrancha - usuwa branch

git checkout nazwaBrancha - przerzuca Cię na branch, którego nazwę podasz

git checkout -b nazwaBrancha - połączenie git branch + git checkout (tworzenie nowego brancha i przeskoczenie na niego od razu)

git merge nazwaBrancha - łączy branch nazwaBrancha z branchem, w którym aktualnie się znajdujemy (np. jeśli znajdujemy się w branchu master, połączymy nazwaBrancha → master)

mkdir nazwaFolderu - tworzy nowy folder

cd nazwaFolderu - wchodzi w dany folder

cd .. - wychodzi do foldera

ls - wyświetla pliki w folderze

git cat - wyświetla zawartość plików znajdujących się w folderze (np. wyświetla tekst w pliku README.txt)

ls -la - wyświetla wszystkie pliki w folderze, również ukryte (np. plik .git, który świadczy o tym, że repozytorium lokalne już zostało stworzone)

2. Komendy dotyczące repozytorium zewnętrznego (Github):

git clone - klonuje repozytorium zewnętrzne na Twój komputer (korzystając z certyfikatu HTTPS); w tym celu kopiujemy adres naszego repo zewnętrzengo na GitHubie

git clone https://github.com/jakubXXX/testGita.git

git remote add origin - połączenie z naszym zdalnym repozytorium (origin to skrót od adresu repo)

git remote add origin https://github.com/jakubXXX/gitTest.git

git push origin nazwaBrancha (czyli wypchnięcie naszych danych z komputera do zewnętrznego repozytorium)

git push origin master (wysyła dane na branch o nazwie master w zewnętrznym repo)

git push origin :nazwaBrancha - usuwa branch z Githuba (nazwa poprzedzona dwukropkiem!)

git push origin :master

Po co Ci ten cały Git?

No właśnie. Tyle dodatkowej roboty, jakby mało było nauki programowania… Coś w tym jednak musi być, skoro cały świat kodowania obraca się wokół GitHuba. Dla rekruterów jest to jedna z pierwszych możliwości zorientowania się, czy w ogóle jest sens zapraszać Cię na rozmowę o pracę. To właśnie dzięki Gitowi będziesz mógł dzielić się swoją pracą nad kodem z całym światem IT i umieszczać swoje projekty na GitHubie. Te projekty, które będzie w przyszłości oglądał jakiś człowiek z HR.

Główne funkcje Gita:

Kontrola wersji

Taki backup kodu. Możesz testować różne alternatywne rozwiazania, których nie wykonujesz bezpośrednio na głównym kodzie, ale na kopi tego kodu w osobnych branchach. W tym przypadku masz pewność, że jeśli spartolisz robotę, to główny kod pozostaje bez zmian. Umożliwia Ci to zachowanie historii i przywracanie wcześniejszych wersji plików.

Rozwiązywanie konfliktów

Pomaga rozwiązywać konflikty, które mogą wystąpić, gdy w jednym czasie, w tym samym obszarze kodu zostały dokonane jakieś zmiany (np. jeśli kilku programistów majstruje jednocześnie przy kodzie)

Łączenie

Jeśli chcemy do kodu zaimplementować nową funckjonaloność, tworzymy nowego brancha i tam testujemy nowe rozwiązanie. Jeśli funckjonalność będzie już gotowa, łącznymy ją z branchem głównym master (czy tam main 😛)

Praca lokalnie: Git przechowuje pełną historię projektu na Twoim komputerze, co umożliwia pracę offline i szybki dostęp do historii zmian

Główne funkcje Githuba:

Przechowywanie kodu

GitHub to platforma, która udostępnia zdalne repozytoria Git, gdzie można przechowywać kod

Współpraca

GitHub oferuje narzędzia do współpracy zespołowej nad projektem. Można zapraszać innych programistów do projektu, recenzować kod, dodawać uwagi i łączyć zmiany w formie tzw. "Pull Requestów". Platforma ułatwia udostępnianie projektów publicznie

Śledzenie błędów

Śledzenie błędów i zgłaszanie problemów związanych z projektem. Można tworzyć tzw. "Issues", gdzie opisuje się napotkane problemy, dyskutuje na ich temat i przypisuje zadania do odpowiednich osób

Integracja z narzędziami

GitHub posiada mozliwość integracji z różnymi narzędziami i usługami, które ułatwiają proces wdrażania, testowania i automatyzacji

W skrócie, Git to narzędzie do kontroli wersji kodu, które pozwala śledzić zmiany w kodzie, tworzyć branche i łączyć zmiany. GitHub natomiast to platforma, która udostępnia zdalne repozytoria Git oraz inne narzędzia, umożliwiające współpracę z innymi programistami, udostępnianie projektów publicznie i integrowanie się z różnymi narzędziami.

Słownik

Git - rozproszony system kontroli wersji, umożliwiający śledzenie i zarządzanie zmianami w kodzie źródłowym

Obszary Gita:

Working Directory - katalog na Twoim komputerze, gdzie dokonujesz zmian w plikach

Staging Area - pośredni obszar, gdzie wybierasz zmiany zatwierdzenia, aby przygotować dane do wypchnięcia na repozytorium

Repository - miejsce, gdzie Git przechowuje pełną historię projektu

Repozytorium - inaczej repo, miejsce przechowujące pełną historię zmian, commity i wszystkie dane projektu w systemie Git:

Repo wewnętrzne - zlokowalizowane na lokalnym systemie, np. w Twoim komputerze

Repo zewnętrzne - zlokowalizowane na zewnętrznej platformie, np. GitHubie

GitHub - platforma dla projektów opartych na Git, która umożliwia przechowywanie, udostępnianie i zarządzanie repozytoriami zdalnie

Branch - odgałęzienie wewnątrz repozytorium Git, pozwalające niezależnie rozwijać kod

Commit - Operacja w systemie Git, zapisująca i zatwierdzająca zmiany w plikach

Wszystkie instrukcje pracy z Git:

1️⃣

Instrukcja nr 1 (wewnętrzne repo)

2️⃣

Instrukcja nr 2 (zewnętrzne repo)

3️⃣

Instrukcja nr 3 (nowe branche)

Moje przemyślenia

Ja to kiedyś rozumiałem tak: Jest sobie ten mityczny GitHub, na którego wszyscy wrzucają swoje projekty. Zarówno młodziaki, jaki i starzy wymiatacze, robią to po to, aby pochwalić się swoimi projektami z resztą świata i wspólnie z innymi kozakami kodowania rozwijać swoje aplikacje. Dodatkowo wiedziałem, że w przyszłości będę musiał umieścić tam swoje projekty, aby potencjalny rekruter mógł ocenić, czy warto zapraszać mnie na rozmowę.

Wiedziałem też, że jest jakiś Git, który jest systemem umożliwiającym w jakiś tam sposób wrzucić ten kod na GitHuba. Myślę, ok. Bułeczka z masłem. Obejrze kiedyś 30-minutowy tutorial na YT i wszystko będę potrafił zrobić. Napiszę kiedyś jakąś apkę. Klikne tu, kliknę tam i gitara. Kod wkleje na GitHuba i wszyscy zadowoleni. Nie ma zatem potrzeby uczyć się tego już teraz. Lepiej skupić się tylko na nauce Javy, a “GitHubów” nauczę się, jaki już będę miał gotowe jakieś rozbudowane aplikacje w Intelij. Nie zakładam konta na GitHubie, bo po co? Skoro i tak nie korzystam, to szkoda czasu.

Oczywiście, jak zwykle się zawiodłem 😂

Okazało się, że ogarnięcie zasad tego “łatwiutkiego” Gita zajęło mi dość sporo czasu i nie wystarczy tylko obejrzeć filmiku na YT. Żeby śmigać w Gicie, trzeba przerobić wiele scenariuszy, aby w pełni zrozumieć sens tego systemu.
To samo tyczyło się konta na GitHubie. Tutaj sprawa była dość zaskakująca, ponieważ brak założonego profilu uniemożliwił w pełni wykorzystać potencjał warsztatów Low-Code, w których uczestniczyłem. Aby zakończyć cały projekt, potrzebowałem założyć profil na Railway.app (platforma hostingowa, która umożliwia łatwe hostowanie i wdrażanie aplikacji internetowych i interfejsów API). Okazało się, że Railway umożliwia autoryzację konta jedynie, jeśli posiadasz pewną historię aktywności/commitów właśnie na… GitHubie! No i dupa zbita 😢

Podsumowując, potrzebowałem dłuższej chwili, żeby załapać cały sens Gita. Jak używać odpowiednich komend, kolejności itd. Zapewne ognąłbym to 2 razy szybciej, gdyby nie fakt, że w międzyczasie pisałem ten post. Mimo tego, jestem bardzo zadowolony, ponieważ uporządkowałem swoją wiedzę. No i mam teraz ściągę z Gita na wieczność 😉

Tak to wygląda. Mam nadzieję, że udało mi się to jakoś wytłumaczyć. Jeśli uważasz, że system z przykładami kodu jest nieczytelny, proszę daj znać na LinkedInie lub po prostu napisz do mnie maila na kuba@javampokaze.pl

`Śledź mnie na LinkedIn:`

`Newsletter`

👋

Popełnianie błędów jest rzeczą naturalną zanim perfekcyjnie opanujemy nowy materiał. Jeśli wyłapałeś jakieś nieprawidłowości w moim tekście, proszę daj mi znać mailowo. Jeśli masz jakieś sugestie lub pytania, proszę napisz do mnie wiadomość: kuba@javampokaze.pl