1. Problem bez kontroli wersji: dlaczego samo kopiowanie plików — to zły pomysł
Zacznijmy od sytuacji z życia. Wyobraź sobie, że pracujesz nad swoim projektem w Javie. Wszystko idzie dobrze, aż nadchodzi moment „eksperymentów”. Postanawiasz coś zmienić, ale boisz się zepsuć działającą wersję. Co robić? Oczywiście, skopiować projekt!
W efekcie na Twoim dysku pojawiają się takie „arcydzieła”:
MyProject/
├── Main.java
├── Main_backup.java
├── Main_final.java
├── Main_final2.java
├── Main_tochno_final.java
├── Main_tochno_tochno_final.java
Znajome? A teraz wyobraź sobie, że do projektu dołączył jeszcze kolega. On też lubi kopiować pliki — tylko po swojemu. Jak rozpoznać, która wersja jest najświeższa i działa? Jak się dowiedzieć, kto co zmienił? Jak wszystko przywrócić, jeśli eksperyment się nie udał?
Bez kontroli wersji:
- Łatwo zgubić albo pomylić działający kod.
- Nie da się „cofnąć” do starej wersji.
- Trudno pracować w dwójkę czy trójkę.
- Chaos i strach przed eksperymentami.
Właśnie te problemy rozwiązują systemy kontroli wersji — takie jak Git.
2. Po co programiście Git?
Git to potężny system kontroli wersji, używany do śledzenia zmian w kodzie źródłowym podczas tworzenia oprogramowania. Pozwala programistom zachowywać różne wersje plików i koordynować pracę wielu osób nad wspólnym projektem.
Podstawowe pojęcia Gita:
Repozytorium
Repozytorium (czyli „repo”) to miejsce, gdzie przechowywana jest cała historia projektu, w tym wszystkie zmiany i wersje plików.
Commity
commit to zapisany stan projektu. Każdy commit w Git zawiera informację o tym, jakie zmiany zostały wprowadzone w projekcie, przez kogo i kiedy. Commity tworzą historię projektu i pozwalają wrócić do dowolnej wcześniejszej wersji.
gitGraph
commit id: "1"
commit id: "2"
commit id: "3"
commit id: "4"
commit id: "5"
commit id: "6"
Każdy commit to „migawka” projektu, która następuje po poprzedniej, tworząc sekwencyjną historię zmian.
Gałęzie
branch to niezależna linia rozwoju. Domyślnie Git tworzy gałąź main. Możesz tworzyć nowe gałęzie dla nowych funkcjonalności lub poprawek, a następnie scalić je z powrotem do gałęzi głównej.
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 gałęzi głównej main „odgałęzia się” gałąź develop do równoległego rozwoju. Po zakończeniu pracy zmiany z develop są scalane z powrotem do main.
3. Podstawowe polecenia Git (to, co jest pod maską)
Poniżej znajduje się lista podstawowych poleceń do pracy z Gitem w terminalu. Ważne jest, aby rozumieć, które komendy leżą u podstaw wszystkich operacji. Jednak my będziemy trzymać się podejścia GUI i nauczymy się wykonywać te działania za pomocą wygodnego interfejsu graficznego IntelliJ IDEA. Traktuj te komendy jako to, co dzieje się „pod maską”.
| Polecenie | Opis |
|---|---|
git init |
Inicjalizuje nowe repozytorium Git w bieżącym katalogu. |
git clone |
Klonuje repozytorium z podanego URL do nowego katalogu. |
git add |
Dodaje pliki do indeksu (staging) przed kolejnym commitem. |
git commit |
Zatwierdza przygotowane zmiany w repozytorium. |
git push |
Wysyła zmiany z repozytorium lokalnego do zdalnego. |
git pull |
Aktualizuje bieżącą gałąź do najnowszej wersji ze zdalnego repozytorium. |
git branch |
Wyświetla, tworzy lub usuwa gałęzie. |
git merge |
Scala zmiany z podanej gałęzi do bieżącej. |
Te polecenia stanowią podstawowy zestaw narzędzi pracy w Git, umożliwiając zarządzanie zmianami kodu, gałęziami i scaleniami w projektach dowolnej wielkości.
sequenceDiagram
participant Katalog roboczy
participant Obszar indeksowania (staging)
participant Repozytorium lokalne
participant Repozytorium zdalne
Katalog roboczy ->> Obszar indeksowania (staging): git add (dodać do indeksu)
Obszar indeksowania (staging) ->> Repozytorium lokalne: git commit (zapisać lokalnie)
Repozytorium lokalne ->> Repozytorium zdalne: git push (wysłać na serwer)
Repozytorium zdalne ->> Katalog roboczy: git pull (pobrać aktualizacje)
4. Trzy miejsca przechowywania kodu
Kiedy będziesz korzystać z systemu kontroli wersji dla swojego kodu, to — mówiąc w uproszczeniu — będzie on przechowywany w trzech miejscach:
1. Repozytorium zdalne
To scentralizowane miejsce przechowywania Twojego kodu, zwykle hostowane na takich serwisach jak GitHub, GitLab lub Bitbucket. Zapewniają one scentralizowane przechowywanie kodu i stanowią podstawę współpracy. Repozytorium zdalne służy jako punkt integracji dla automatyzacji procesów, takich jak budowanie, testowanie i wdrażanie aplikacji.
2. Repozytorium lokalne
Repozytorium lokalne to Twoja osobista kopia kodu, przechowywana na Twoim komputerze. W tym repozytorium możesz wykonywać wszystkie operacje Git (commity, rozgałęzienia, scalania) bez konieczności połączenia z internetem.
3. Katalog roboczy
Katalog roboczy na Twoim komputerze zawiera aktualne pliki projektu, nad którymi w danym momencie pracujesz. To miejsce, w którym możesz przeglądać i zmieniać pliki, dodawać nową funkcjonalność lub naprawiać błędy.
Te elementy wspólnie zapewniają potężną infrastrukturę do zarządzania kodem źródłowym, pozwalając programistom zarządzać historią projektu i współpracować.
5. GitHub — Twoje portfolio
GitHub — to wiodąca platforma webowa do hostingu kodu źródłowego, wykorzystująca system kontroli wersji Git. Założona w 2008 roku, szybko stała się jednym z kluczowych narzędzi dla programistów na całym świecie.
GitHub umożliwia użytkownikom tworzenie repozytoriów do zarządzania projektami, kontrolowania i śledzenia zmian w kodzie oraz współpracy z innymi programistami. Dla współczesnego programisty profil na GitHubie jest ważną częścią portfolio, które można pokazać potencjalnym pracodawcom.
6. Tworzenie pierwszego repozytorium na GitHubie
Krok 1. Wejdź na https://github.com i zarejestruj się.
Krok 2. Kliknij przycisk New repository, aby utworzyć nowe repozytorium.
Krok 3. Ustaw parametry repozytorium:
- Nazwa repozytorium: wymyśl sensowną nazwę.
- Publiczne czy prywatne: do projektów edukacyjnych lepiej wybrać „Public”, aby inni mogli go zobaczyć.
- Add a README file: koniecznie zaznacz tę opcję. README to „wizytówka” Twojego projektu.
- Add .gitignore: kliknij listę rozwijaną i wybierz szablon dla swojego języka.
- Choose a license: można pominąć.
- Kliknij
Create repository.
Krok 4. Gratulacje, Twoje pierwsze zdalne repozytorium zostało utworzone!
7. Instalacja i konfiguracja Gita
Chociaż podstaw Gita można uczyć się przez komendy konsolowe (jak pokazano na wideo), w codziennej pracy 99% programistów używa właśnie wygodnych narzędzi wbudowanych w środowisko programistyczne. Naszym celem jest nauczyć Cię pracować tak, jak robią to profesjonaliści.
Interfejs do pracy z Gitem we wszystkich nowoczesnych IDE od JetBrains — czy to IntelliJ IDEA dla Java/Kotlin, Rider dla C# czy PyCharm dla Pythona — jest praktycznie identyczny. To oznacza, że nauczywszy się pracy z Gitem w jednym środowisku, łatwo zastosujesz te umiejętności w każdym innym. Dlatego będziemy używać IntelliJ IDEA jako uniwersalnego przykładu. Wszystko, co tu zobaczysz, będzie wyglądać i działać dokładnie tak samo w Twoim ulubionym IDE.
Aby pracować z Gitem na Twoim komputerze, Git trzeba najpierw zainstalować. Jeśli używasz IntelliJ IDEA, najprawdopodobniej zaproponuje ona automatyczną instalację Gita, jeśli nie zostanie znaleziony w systemie. Rekomendujemy się na to zgodzić — to najprostsza droga.
Zamknij bieżący projekt, wybierając File > Close Project, i kliknij Clone Repository.
Jeśli jednak chcesz zainstalować go ręcznie, skorzystaj z oficjalnej strony: https://git-scm.com/downloads.
8. Krótko o historii: main vs master
Wcześniej domyślna gałąź w Gicie nazywała się master. Jednak w 2020 roku społeczność programistów i największe platformy, w tym GitHub, przeszły na bardziej neutralny termin — main.
Warto o tym wiedzieć, ponieważ w niektórych starszych artykułach lub projektach wciąż możesz spotkać się ze wzmianką o gałęzi master. W naszych wykładach i we współczesnych projektach gałęzią główną zawsze będzie main.
Więcej o przejściu na main możesz przeczytać pod poniższymi linkami:
GO TO FULL VERSION