Git to lokalny, rozproszony system kontroli wersji. Śledzi zmiany w plikach, zapisuje kolejne migawki projektu i pozwala bezpiecznie wracać do wcześniejszych wersji. Podstawowy cykl pracy wygląda tak: modyfikujesz pliki, dodajesz wybrane zmiany do przechowalni, tworzysz commit, a następnie opcjonalnie wysyłasz go do zdalnego repozytorium.
Czym jest Git i jak działa?
Git przechowuje historię projektu w repozytorium. Większość operacji wykonuje lokalnie, więc możesz przeglądać historię, tworzyć commity i pracować nad plikami bez połączenia z internetem. Synchronizacja z serwerem jest potrzebna dopiero wtedy, gdy chcesz pobrać zmiany innych osób albo wysłać własne.
Git zapisuje stan projektu jako migawki, a nie wyłącznie jako listę różnic między plikami. Commit opisuje więc konkretny stan projektu w danym momencie. Dzięki temu łatwiej porównywać wersje, odtwarzać wcześniejsze stany i analizować historię.
Nie należy mylić Gita z GitHubem ani GitLabem. Git jest narzędziem działającym na komputerze. GitHub i GitLab to platformy, na których można przechowywać zdalne repozytoria, współpracować nad kodem i przeglądać zmiany przez przeglądarkę.
Trzy stany plików w Git
Najważniejszy model pracy z Gitem obejmuje katalog roboczy, staging area oraz repozytorium. Zrozumienie tej kolejności wyjaśnia, dlaczego samo zapisanie pliku nie wystarcza do utworzenia commita.
- Katalog roboczy – znajdują się w nim pliki, które otwierasz i edytujesz.
- Staging area – przechowalnia, nazywana też indeksem, zawiera zmiany przygotowane do najbliższego commita.
- Repozytorium – lokalna baza danych Gita, w której trwale zapisane są commity i historia projektu.
Po zmianie pliku Git widzi go jako zmodyfikowany. Polecenie git add kopiuje aktualny stan wybranego pliku do staging area. Dopiero git commit zapisuje zawartość przechowalni jako nową migawkę w repozytorium. Możesz więc przygotować do jednego commita tylko część zmian, nawet jeśli w katalogu roboczym zmodyfikowano więcej plików.
Jak zacząć pracę z Gitem?
Najpierw sprawdź, czy Git jest już dostępny w systemie. Jeśli go nie ma, zainstaluj go z użyciem instalatora właściwego dla Windows, macOS albo swojej dystrybucji Linuksa. Następnie wykonaj konfigurację:
- Sprawdź instalację poleceniem
git --version. - Ustaw nazwę autora commitów:
git config --global user.name "Imię Nazwisko". - Ustaw adres e-mail:
git config --global user.email "[email protected]". - Wyświetl konfigurację poleceniem
git config --list.
Nowe repozytorium możesz utworzyć w istniejącym katalogu:
cd nazwa-projektu
git initPolecenie git init tworzy ukryty katalog .git z metadanymi i bazą historii. Nie modyfikuje pozostałych plików. Jeśli projekt już istnieje na serwerze, pobierz jego lokalną kopię za pomocą:
git clone https://example.com/projekt.gitKlonowanie tworzy lokalne repozytorium wraz z historią i kopią roboczą projektu.
Codzienny workflow w Git
Typowy cykl pracy zaczyna się od edycji plików i kończy na wysłaniu commita do zdalnego repozytorium. Przed każdą operacją dobrze sprawdzić bieżący stan:
| Komenda | Działanie |
|---|---|
git status |
Pokazuje zmodyfikowane, nowe i przygotowane pliki. |
git add plik.txt |
Dodaje wskazany plik do staging area. |
git add . |
Dodaje zmiany z bieżącego katalogu do przechowalni. |
git commit -m "Opis" |
Zapisuje przygotowane zmiany jako commit. |
git push origin main |
Wysyła lokalne commity do zdalnego repozytorium. |
git pull |
Pobiera zmiany ze zdalnego repozytorium i integruje je z bieżącą gałęzią. |
git log |
Wyświetla historię commitów. |
W praktyce podstawowy przebieg może wyglądać tak:
git status
git add README.md
git commit -m "Aktualizacja dokumentacji"
git push origin mainPrzed pierwszym commitem sprawdź następujące rzeczy:
- Czy pracujesz w właściwym repozytorium i na właściwej gałęzi.
- Czy
git statuspokazuje pliki, które chcesz zapisać. - Czy wszystkie wymagane zmiany trafiły do staging area.
- Czy opis commita jasno mówi, co zostało zmienione.
Commit zapisuje zmiany lokalnie. Dopiero git push przesyła je na serwer, a git pull pobiera zmiany przygotowane przez innych. To rozdzielenie pozwala pracować offline i decydować, kiedy synchronizować projekt.
Jak pracować z gałęziami?
Gałąź izoluje zmiany od głównej linii projektu. Przy nowej funkcji, poprawce błędu albo eksperymencie możesz utworzyć osobną gałąź, nie modyfikując bezpośrednio main.
git switch -c nazwa-funkcjiPolecenie tworzy gałąź i od razu na nią przełącza. Listę gałęzi wyświetlisz przez git branch, a powrót do głównej gałęzi wykonasz tak:
git switch mainPo zakończeniu pracy możesz scalić zmiany z bieżącą gałęzią:
git merge nazwa-funkcjiJeśli ten sam fragment pliku został zmieniony w obu gałęziach, Git zgłosi konflikt. Trzeba wtedy ręcznie wybrać właściwą wersję, zapisać plik, dodać go do staging area i zakończyć scalanie commitem. W zespołach merge często poprzedza przegląd kodu za pomocą pull requestu lub merge requestu.
Co zrobić, gdy coś pójdzie nie tak?
„fatal: not a git repository” oznacza, że terminal nie znajduje repozytorium w bieżącym katalogu. Przejdź do właściwego folderu poleceniem cd albo zainicjalizuj nowe repozytorium przez git init.
„Authentication failed” przy git push wskazuje na problem z dostępem do zdalnego repozytorium. Sprawdź adres za pomocą git remote -v oraz sposób uwierzytelniania. Platformy takie jak GitHub mogą wymagać tokenu dostępu przy HTTPS albo konfiguracji klucza SSH. Klucz prywatny SSH powinien pozostać wyłącznie na Twoim urządzeniu.
Jeśli po commicie zauważysz, że zabrakło jednego pliku, a commit nie został jeszcze wysłany, możesz go poprawić:
git add brakujacy-plik.txt
git commit --amend --no-editNie poprawiaj w ten sposób commita, który został już udostępniony innym osobom przez git push. Zmiana historii może utrudnić synchronizację pozostałym użytkownikom.
Git najlepiej opanować przez powtarzanie prostego cyklu: status, add, commit, a po sprawdzeniu zmian także push. Najważniejsze jest rozróżnienie między plikami roboczymi, staging area i lokalnym repozytorium. Gdy ten model jest jasny, kolejne komendy służą już głównie do porządkowania historii i współpracy z zespołem.
