1. Problem bez kontroli wersji: dlaczego zwykle kopiowanie plikow to zly pomysl
Zacznijmy od sytuacji z zycia. Wyobraz sobie, ze pracujesz nad swoim projektem w Kotlinie. Wszystko idzie dobrze, az nadchodzi moment „eksperymentow”. Postanawiasz cos zmienic, ale boisz sie zepsuc dzialajaca wersje. Co robic? Oczywiscie, skopiowac projekt!
W efekcie na dysku pojawiaja sie takie dziela sztuki:
MyProject/
├── Main.kt
├── Main_backup.kt
├── Main_final.kt
├── Main_final2.kt
├── Main_exactly_final.kt
├── Main_exactly_exactly_final.kt
Znajome? A teraz wyobraz sobie, ze do projektu dolaczyl jeszcze kolega. On tez lubi kopiowac pliki — tylko po swojemu. Jak zrozumiec, gdzie jest najnowsza i dzialajaca wersja? Jak sie dowiedziec, kto co zmienil? Jak wszystko przywrocic, jesli eksperyment sie nie udal?
Bez kontroli wersji:
- Latwo zgubic albo pomylic dzialajacy kod.
- Nie da sie „cofnac” do starszej wersji.
- Trudno pracowac we dwojke albo we trojke.
- Chaos i strach przed eksperymentami.
Wlasnie te problemy rozwiazuja systemy kontroli wersji — takie jak Git.
Wideo
Obejrzyj wyklad jednego z glownych mentorow Uniwersytetu CodeGym, ktory wprowadzi cie w swiat Git — kluczowej technologii dla kazdego nowoczesnego programisty.
Wideo sklada sie z dwoch czesci:
- Najpierw omowisz podstawy pracy z Git przez terminal. To fundamentalne podejscie pomoze ci zrozumiec, co dzieje sie „pod maska” systemu.
- Nastepnie przejdziesz do praktyki w IntelliJ IDEA, gdzie nauczysz sie wykonywac te same operacje za pomoca wygodnego interfejsu graficznego — tak, jak robia to na co dzien profesjonalisci.
2. Po co programiscie Git?
Git to potezny system zarzadzania wersjami, uzywany do sledzenia zmian w kodzie zrodlowym podczas tworzenia oprogramowania. Umozliwia programistom zapisywanie roznych wersji plikow oraz koordynowanie pracy kilku osob nad wspolnym projektem.
Podstawowe pojecia Git:
Repozytorium
Repozytorium albo „repo” to miejsce, w ktorym przechowywana jest cala historia projektu, lacznie ze wszystkimi zmianami i wersjami plikow.
Commity
commit to zapisany stan projektu. Kazdy commit w Git zawiera informacje o tym, jakie zmiany zostaly wprowadzone do projektu, przez kogo i kiedy. Commity tworza historie projektu i pozwalaja wrocic do dowolnej poprzedniej wersji.
gitGraph
commit id: "1"
commit id: "2"
commit id: "3"
commit id: "4"
commit id: "5"
commit id: "6"
Kazdy commit to „migawka” projektu, ktora nastepuje po poprzednim, tworzac spojna historie zmian.
Galezie
branch to niezalezna linia rozwoju. Domyslnie Git tworzy galaz main. Mozesz tworzyc nowe galezie do implementacji nowych funkcji albo poprawek, a nastepnie scalac je z powrotem z glowna galezia.
gitGraph
commit id: "1"
commit id: "2"
branch develop
commit id: "3"
commit id: "4"
commit id: "5"
checkout main
commit id: "6"
commit id: "7"
merge develop
commit id: "8"
commit id: "9"
Od glownej galezi main „odgalezia sie” galaz develop do rownoleglej pracy. Po zakonczeniu zmian, zmiany z develop sa scalane z powrotem do main.
3. Podstawowe komendy Git (to, co dzieje sie pod maska)
Ponizej znajduje sie lista podstawowych polecen do pracy z Git przez terminal. Wazne jest zrozumienie, jakie komendy stanowia podstawe wszystkich operacji. Jednak my bedziemy trzymac sie podejscia GUI i nauczymy sie wykonywac wszystkie te czynnosci za pomoca wygodnego interfejsu graficznego IntelliJ IDEA. Traktuj te komendy jako to, co dzieje sie „pod maska”.
| Komenda | Opis |
|---|---|
git init |
Inicjalizuje nowe repozytorium Git w biezacym katalogu. |
git clone |
Klonuje repozytorium z URL do nowego katalogu. |
git add |
Dodaje pliki do indeksu przed kolejnym commitem. |
git commit |
Zapisuje przygotowane zmiany w repozytorium. |
git push |
Wysyla zmiany z lokalnego repozytorium do zdalnego. |
git pull |
Aktualizuje biezaca galaz do najnowszej wersji ze zdalnego repozytorium. |
git branch |
Pokazuje, tworzy lub usuwa galezie. |
git merge |
Scala zmiany z podanej galezi do biezacej galezi. |
Te komendy stanowia podstawowe narzedzia pracy w Git, pozwalajac zarzadzac zmianami kodu, galeziami i scaleniami w projektach dowolnej wielkosci.
sequenceDiagram
participant Katalog roboczy
participant Obszar indeksowania (Staging)
participant Repozytorium lokalne
participant Repozytorium zdalne
Katalog roboczy ->> Obszar indeksowania (Staging): git add (Przygotowac)
Obszar indeksowania (Staging) ->> Repozytorium lokalne: git commit (Zapisac lokalnie)
Repozytorium lokalne ->> Repozytorium zdalne: git push (Wyslac na serwer)
Repozytorium zdalne ->> Katalog roboczy: git pull (Pobrac aktualizacje)
4. Cztery stany (miejsca przechowywania) kodu
Gdy bedziesz korzystac z systemu kontroli wersji dla swojego kodu, bedzie on logicznie przechodzil przez cztery stany:
1. Katalog roboczy (Working Directory)
Katalog roboczy na twoim komputerze zawiera aktualne pliki projektu, nad ktorymi w danej chwili pracujesz. To miejsce, w ktorym mozesz widziec i zmieniac pliki, pisac kod, dodawac nowa funkcjonalnosc lub poprawiac bledy.
2. Obszar indeksowania (Staging Area)
To posrednia strefa pomiedzy twoim katalogiem roboczym a lokalnym repozytorium. W terminologii interfejsu IDE (GUI) sa to te same checkboxy, ktore zaznaczasz przy zmienionych plikach, zanim nacisniesz przycisk Commit. Sam wybierasz, ktore pliki i zmiany sa gotowe, aby wejsc do kolejnej „migawki” historii.
3. Repozytorium lokalne (Local Repository)
Repozytorium lokalne to twoja osobista kopia historii kodu, przechowywana na twoim komputerze. W tym repozytorium mozesz wykonywac wszystkie operacje Git (commity, rozgalezienia, scalenia) bez koniecznosci polaczenia z internetem.
4. Repozytorium zdalne (Remote Repository)
To scentralizowane miejsce przechowywania twojego kodu, zwykle hostowane na serwisach takich jak GitHub, GitLab czy Bitbucket. Zapewniaja one niezawodne przechowywanie kodu na serwerach i stanowia podstawe wspolpracy zespolowej.
5. GitHub — twoje portfolio
Wazne jest wyrazne rozroznienie dwoch pojec: Git i GitHub. Git to program, ktory dziala lokalnie na twoim komputerze (nawet bez internetu) i pilnuje wersji plikow. A GitHub to usluga w chmurze (strona), gdzie przechowywane sa zdalne kopie twoich repozytoriow Git.
GitHub to wiodaca platforma WWW do hostowania kodu zrodlowego, korzystajaca z systemu kontroli wersji Git. Zalozona w 2008 roku, szybko stala sie jednym z kluczowych narzedzi dla programistow na calym swiecie.
GitHub umozliwia uzytkownikom tworzenie repozytoriow do zarzadzania projektami, kontrolowanie i sledzenie zmian w kodzie oraz wspolprace z innymi programistami. Dla nowoczesnego programisty profil na GitHubie jest wazna czescia portfolio, ktore mozna pokazac potencjalnym pracodawcom.
6. Tworzenie pierwszego repozytorium na GitHubie
Krok 1. Wejdz na https://github.com i zarejestruj sie.
Krok 2. Kliknij przycisk New repository, aby utworzyc nowe repozytorium.
Krok 3. Ustaw parametry repozytorium:
- Nazwa repozytorium: wymysl sensowna nazwe.
- Publiczne czy prywatne: dla projektow edukacyjnych lepiej wybrac „Public”, zeby inni mogli je zobaczyc.
- Add a README file: koniecznie zaznacz ten checkbox. README to „twarz” twojego projektu.
- Add .gitignore: kliknij liste rozwijana i wybierz szablon Kotlin (albo Java). Uchroni to repozytorium przed trafieniem do niego ciezkich rezultatow builda oraz lokalnych ustawien IDE.
- Choose a license: mozna pominac.
- Kliknij
Create repository.
Krok 4. Gratulacje — twoje pierwsze zdalne repozytorium zostalo utworzone!
7. Instalacja i konfiguracja Git
Choc podstaw Git mozna uczyc sie przez polecenia konsolowe (jak pokazano w wideo), w codziennej pracy 99% programistow korzysta z wygodnych narzedzi wbudowanych w srodowisko programistyczne. Naszym celem jest nauczyc cie pracowac tak, jak robia to profesjonalisci.
Interfejs do pracy z Git we wszystkich nowoczesnych IDE od JetBrains — czy to IntelliJ IDEA dla Kotlin/Java, Rider dla C#, czy PyCharm dla Pythona — jest praktycznie identyczny. Oznacza to, ze gdy nauczysz sie pracowac z Git w jednym srodowisku, latwo zastosujesz te umiejetnosci w innym. Dlatego uzyjemy IntelliJ IDEA jako uniwersalnego przykladu. Wszystko, co tu zobaczysz, bedzie wygladalo i dzialalo tak samo w twoim ulubionym IDE.
Aby pracowac z Git na swoim komputerze, musisz najpierw zainstalowac Git. Jesli uzywasz IntelliJ IDEA, najprawdopodobniej zaproponuje ona automatyczna instalacje Git, jesli nie zostanie on znaleziony w systemie. Zalecamy zgodzic sie na te propozycje — to najprostsza droga.
Zamknij biezacy projekt, wybierajac w gornym menu File | Close Project. Na ekranie startowym (Welcome Screen) kliknij przycisk Clone Repository (w niektorych wersjach interfejsu moze nazywac sie Get from VCS).
Jesli chcesz zainstalowac go recznie, skorzystaj z oficjalnej strony: https://git-scm.com/downloads.
Wazny niuans
Gdy bedziesz robic swoj pierwszy commit w IDE, IntelliJ IDEA poprosi cie o przedstawienie sie — podanie nazwy uzytkownika i e-maila. To niezwykle wazne, aby podac dokladnie ten e-mail, na ktory zarejestrowales swoje konto na GitHubie.
Chodzi o to, ze GitHub laczy autorstwo twoich commitow z twoim profilem wlasnie po tym adresie e-mail. Jesli adresy beda sie zgadzac, obok twoich commitow pojawi sie twoj avatar, a na stronie twojego profilu zaczna wypelniac sie te upragnione „zielone kwadraciki” aktywnosci, ktore pracodawcy tak chetnie oceniaja.
8. Troche historii: main vs master
Wczesniej domyslna galaz w Git nazywala sie master. Jednak w 2020 roku spolecznosc programistow oraz najwieksze platformy, w tym GitHub, przeszly na uzywanie bardziej neutralnego terminu — main.
Warto o tym wiedziec, bo w niektorych starszych artykulach albo projektach nadal mozesz spotkac wzmianke o galezi master. W naszych wykladach i we wspolczesnych projektach glowna galezia zawsze bedzie main.
Wiecej o przejsciu na main mozesz przeczytac pod nastepujacymi linkami:
GO TO FULL VERSION