Git dla początkujących: commit, gałąź i merge bez stresu

Po co w ogóle Git

Wyobraź sobie, że piszesz projekt i co jakiś czas zapisujesz kopię folderu: projekt, projekt-dziala, projekt-final, projekt-final-2. Po miesiącu nie wiesz, czym różnią się te wersje ani która była ostatnią działającą. Git rozwiązuje dokładnie ten problem, tylko elegancko.

Każdy zapis stanu projektu w Gicie to commit – migawka z opisem, datą i autorem. Możesz w dowolnej chwili wrócić do starszej migawki, porównać dwie wersje linijka po linijce albo sprawdzić, kto i dlaczego zmienił konkretny fragment kodu.

Git działa lokalnie, na Twoim komputerze, więc nie potrzebujesz internetu, żeby z niego korzystać. Serwisy takie jak GitHub, GitLab czy Bitbucket to osobne usługi, które przechowują kopię repozytorium w chmurze i ułatwiają współpracę.

Git przydaje się nawet wtedy, gdy pracujesz zupełnie sam. Pozwala bez strachu eksperymentować: jeśli nowy pomysł nie wypali, wracasz do ostatniej działającej wersji jedną komendą. Z czasem historia commitów staje się też dziennikiem Twojej nauki – widać w niej, jak rosły projekty i jakie problemy po drodze rozwiązywałeś. Właśnie dlatego rekruterzy tak chętnie zaglądają do repozytoriów kandydatów.

Trzy strefy: katalog roboczy, poczekalnia i historia

Kluczem do zrozumienia Gita są trzy miejsca, przez które przechodzą Twoje zmiany. Katalog roboczy to pliki, które edytujesz. Poczekalnia (ang. staging area) to lista zmian przygotowanych do zapisania. Historia to zatwierdzone commity.

git init
git status
git add index.html
git commit -m "Dodaj szkielet strony"
git log --oneline

Po co poczekalnia? Dzięki niej możesz zmienić pięć plików, a zapisać w jednym commicie tylko dwa, które dotyczą tej samej poprawki. Historia jest wtedy czytelna: każdy commit opowiada jedną małą historię.

Komenda git status jest Twoim najlepszym przyjacielem. Uruchamiaj ją często – pokazuje, które pliki są zmienione, które czekają w poczekalni i na jakiej gałęzi się znajdujesz.

Gałęzie i łączenie zmian

Gałąź (branch) to niezależna linia rozwoju projektu. Tworzysz ją, gdy chcesz spróbować czegoś nowego bez ryzyka zepsucia działającej wersji. Główna gałąź zwykle nazywa się main.

git switch -c nowy-naglowek
# edytujesz pliki, potem:
git add .
git commit -m "Zmień nagłówek strony"
git switch main
git merge nowy-naglowek

Czasem Git nie potrafi sam połączyć zmian, bo na obu gałęziach zmodyfikowano tę samą linię. Powstaje wtedy konflikt. Nie panikuj: Git oznacza w pliku oba warianty znacznikami <<<<<<< i >>>>>>>. Wybierasz właściwą wersję, usuwasz znaczniki, dodajesz plik do poczekalni i robisz commit. Edytory takie jak VS Code pokazują konflikty graficznie, z przyciskami do wyboru wariantu.

GitHub i praca ze zdalnym repozytorium

Zdalne repozytorium to kopia Twojego projektu na serwerze. Komenda git push wysyła do niego Twoje commity, a git pull pobiera zmiany, które wprowadzili inni. Przy pierwszym połączeniu musisz skonfigurować uwierzytelnianie – najwygodniej przez klucz SSH albo menedżer poświadczeń.

W pracy zespołowej zmiany rzadko trafiają prosto do main. Zamiast tego tworzysz gałąź, wypychasz ją na serwer i otwierasz pull request – prośbę o włączenie zmian. Koledzy mogą wtedy przejrzeć kod, zostawić komentarze i zaakceptować poprawki. Ten proces nazywa się code review i jest jednym z najlepszych sposobów nauki.

Dla osoby szukającej pierwszej pracy profil na GitHubie pełni rolę portfolio. Regularne commity z sensownymi opisami pokazują rekruterowi, że umiesz pracować systematycznie.

Na start wystarczy darmowe konto. Zadbaj o czytelną nazwę użytkownika, zdjęcie lub awatar oraz krótki opis profilu, w którym napiszesz, czego się uczysz.

Cofanie zmian bez paniki

Największa zaleta Gita ujawnia się wtedy, gdy coś pójdzie nie tak. Zmieniłeś plik i żałujesz? Komenda git restore przywróci go do stanu z ostatniego commitu. Dodałeś do poczekalni za dużo? git restore --staged wycofa plik z poczekalni, ale zostawi Twoje zmiany.

Jeśli błędny commit trafił już na serwer, nie przepisuj historii. Użyj git revert, który tworzy nowy commit odwracający zmiany starego. Historia pozostaje uczciwa, a współpracownicy nie muszą niczego naprawiać u siebie. Komendy takie jak git reset --hard czy wymuszone push zostaw na później, gdy dobrze zrozumiesz, co robią.

Ściągawka i dobre nawyki

Pisz opisy commitów w trybie rozkazującym i konkretnie: „Dodaj walidację formularza kontaktowego” mówi więcej niż „poprawki”. Rób małe commity – łatwiej je zrozumieć i łatwiej cofnąć. Nigdy nie zapisuj w repozytorium haseł, kluczy API ani plików z danymi osobowymi; do ignorowania plików służy plik .gitignore.

Najczęstsze pytania