Czy znasz system Git? Praktyczny przewodnik po systemie kontroli wersji

Git

Oleksandr Vykhor

25-09-2026 15:40:29

Czy znasz system Git? Praktyczny przewodnik po systemie kontroli wersji

„Czy znasz Gita?” to jedno z najczęstszych pytań na rozmowach rekrutacyjnych dla programistów, i nie bez powodu. Git jest dziś używany niemal w każdym projekcie, od małego osobistego bloga po jądro Linuksa. W tym artykule wyjaśnimy, czym jest Git, jak działa od środka, jakich poleceń używa się na co dzień, jak zespoły organizują z nim pracę i co zrobić, gdy coś pójdzie nie tak.

Czym jest Git?

Git to rozproszony system kontroli wersji. Zapisuje historię zmian w projekcie, pozwala wrócić do dowolnego wcześniejszego stanu, równolegle pracować nad kilkoma zadaniami i łączyć pracę wielu programistów.

Gita stworzył Linus Torvalds w 2005 roku na potrzeby rozwoju jądra Linuksa. Głównymi celami były szybkość, niezawodność i obsługa dużego, rozproszonego zespołu.

Scentralizowane i rozproszone systemy kontroli wersji

Systemy scentralizowane (np. SVN) przechowują historię na jednym centralnym serwerze. Programiści dostają tylko bieżącą wersję plików, a większość operacji wymaga połączenia z serwerem.
Systemy rozproszone (Git, Mercurial) dają każdemu programiście pełną kopię repozytorium z całą historią. Commitować, przeglądać historię, tworzyć gałęzie i porównywać wersje można bez internetu. Zdalny serwer, taki jak GitHub czy GitLab, to po prostu kolejna kopia służąca do wymiany zmian.

Ważne jest też, by nie mylić Gita z GitHubem. Git to narzędzie działające na Twoim komputerze. GitHub, GitLab i Bitbucket to serwisy, które przechowują repozytoria Git i dodają pull requesty, code review, CI/CD oraz śledzenie zadań.

Jak działa Git: kluczowe pojęcia

Migawki, a nie różnice

Każdy commit w Gicie to migawka całego projektu w danym momencie, a do tego autor, data, opis i odnośnik do commita nadrzędnego. Niezmienione pliki nie są kopiowane ponownie: Git po prostu wskazuje na już zapisaną wersję. Każdy commit ma unikalny identyfikator, czyli hash w rodzaju a1b2c3d.

Trzy obszary

Aby rozumieć Gita, trzeba wiedzieć, gdzie znajdują się Twoje zmiany:

Katalog roboczy (working directory): pliki, które właśnie edytujesz.
Poczekalnia (staging area, index): zmiany wybrane do następnego commita za pomocą git add.
Repozytorium: zapisana historia commitów w folderze .git.

Poczekalnia pozwala zacommitować tylko część zmian, na przykład oddzielić poprawkę błędu od refaktoryzacji, nawet jeśli obie wprowadzono w tym samym pliku.

Gałęzie i HEAD

Gałąź (branch) w Gicie to po prostu lekki wskaźnik na commit. Utworzenie gałęzi jest natychmiastowe i prawie nic nie kosztuje, dlatego programiści tworzą osobną gałąź dla każdego zadania lub poprawki. HEAD to wskaźnik na gałąź (lub commit), na której aktualnie się znajdujesz.

Polecenia na co dzień

# Jednorazowa konfiguracja
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

# Utwórz projekt lub skopiuj istniejący
git init
git clone git@github.com:user/project.git

# Sprawdź, co się zmieniło
git status
git diff            # zmiany jeszcze niedodane do poczekalni
git diff --staged   # zmiany, które trafią do następnego commita

# Zapisz zmiany
git add app/models/user.rb
git commit -m "Add email validation to User"

# Historia
git log --oneline --graph --all

Praca z gałęziami

git switch -c feature/user-avatars   # utwórz gałąź i przełącz się na nią
git switch main                      # wróć z powrotem
git branch                           # lista lokalnych gałęzi
git branch -d feature/user-avatars   # usuń scaloną gałąź

Starsze polecenie git checkout robi to samo i jeszcze więcej, ale git switch (dla gałęzi) i git restore (dla plików) są czytelniejsze i bezpieczniejsze.

Praca ze zdalnym repozytorium

git remote -v                          # lista zdalnych repozytoriów
git fetch                              # pobierz zmiany bez ich stosowania
git pull                               # fetch + merge (lub rebase) do bieżącej gałęzi
git push -u origin feature/user-avatars  # opublikuj gałąź

Merge czy rebase

Zmiany z jednej gałęzi do drugiej można przenieść na dwa sposoby:

Merge (git merge) łączy gałęzie i tworzy commit scalający. Historia zostaje dokładnie taka, jaka była, ale może stać się nieczytelna.
Rebase (git rebase) przenosi Twoje commity na szczyt innej gałęzi, dając czystą, liniową historię. Jednak przepisuje commity, tworząc nowe hashe.

# Zaktualizuj swoją gałąź najnowszym main
git switch feature/user-avatars
git fetch origin
git rebase origin/main

# Albo zrób merge
git merge origin/main

Złota zasada: nie rób rebase commitów, na których inni oparli już swoją pracę, na przykład wspólnej gałęzi main. Rebase własnej lokalnej gałęzi zadania to normalna praktyka.

Rozwiązywanie konfliktów

Konflikt powstaje, gdy dwie gałęzie zmieniają te same linie tego samego pliku. Git zatrzymuje się i oznacza problematyczne miejsce:

<<<<<<< HEAD
  validates :email, presence: true
=======
  validates :email, presence: true, uniqueness: true
>>>>>>> feature/unique-emails

Edytujesz plik, zostawiając właściwą wersję, usuwasz znaczniki, a następnie wykonujesz git add i kontynuujesz przez git commit (przy merge) lub git rebase --continue (przy rebase). Jeśli wszystko za bardzo się zaplątało, git merge --abort lub git rebase --abort przywróci stan sprzed rozpoczęcia operacji.

Cofanie zmian

Umiejętność naprawiania błędów odróżnia pewnego siebie użytkownika Gita od początkującego:

git restore config/routes.rb         # odrzuć niedodane zmiany w pliku
git restore --staged config/routes.rb  # usuń plik z poczekalni, zachowując zmiany

git commit --amend                   # popraw ostatni commit (opis lub zawartość)

git reset --soft HEAD~1              # cofnij ostatni commit, zmiany zostają w poczekalni
git reset --hard HEAD~1              # cofnij ostatni commit i USUŃ zmiany

git revert a1b2c3d                   # utwórz nowy commit, który cofa a1b2c3d

Używaj git revert dla commitów już wypchniętych na serwer: nie przepisuje historii, więc jest bezpieczny dla wspólnych gałęzi.
Używaj git reset i --amend tylko dla lokalnych commitów, których nikt inny nie ma.
Uważaj na --hard: niezacommitowane zmiany zostaną utracone.

I koło ratunkowe: git reflog pokazuje wszystkie miejsca, w których był HEAD, także commity „utracone” po reset lub nieudanym rebase. Pracę, która choć raz została zacommitowana, prawie zawsze da się odzyskać.

git reflog
git reset --hard HEAD@{2}   # wróć do stanu sprzed dwóch przesunięć

Przydatne polecenia, które warto znać

git stash: tymczasowo odłóż niedokończone zmiany, np. aby przełączyć się na pilny błąd. Przywrócisz je przez git stash pop.
git cherry-pick <hash>: skopiuj konkretny commit do bieżącej gałęzi.
git blame <file>: sprawdź, kto ostatni zmieniał każdą linię i w którym commicie.
git bisect: wyszukiwanie binarne w historii, aby znaleźć commit, który wprowadził błąd.
git tag v1.2.0: oznacz wydanie.
git rebase -i HEAD~3: interaktywny rebase, aby połączyć, zmienić kolejność lub opisy swoich ostatnich lokalnych commitów przed otwarciem pull requesta.

Modele pracy w zespole

GitHub Flow: main zawsze nadaje się do wdrożenia; każda zmiana przechodzi przez krótko żyjącą gałąź zadania i pull request z code review. Prosty i popularny model dla aplikacji webowych.
Git Flow: osobne gałęzie develop, release/* i hotfix/*. Pasuje do produktów z planowanymi wydaniami, ale jest ciężki przy ciągłym wdrażaniu.
Trunk-based development: wszyscy bardzo często integrują małe zmiany z main, korzystając z feature flag. Sprawdza się przy dobrych testach automatycznych.

Git w projekcie Rails

Nowa aplikacja Rails ma już plik .gitignore. Ważne, by sekrety i generowane pliki nie trafiły do repozytorium:

# .gitignore (kluczowe linie)
/config/master.key
/config/credentials/*.key
/log/*
/tmp/*
/storage/*
/public/assets
/node_modules
.env

Nigdy nie commituj config/master.key ani plików .env. Zaszyfrowany credentials.yml.enc można commitować, ale klucz trzeba przekazać na serwer osobno.
Commituj Gemfile.lock i db/schema.rb, aby wszyscy programiści i serwery mieli te same wersje gemów i strukturę bazy.
Trzymaj migrację i kod od niej zależny w tym samym commicie lub pull requeście.

Jeśli sekret trafił do commita przez pomyłkę, nie wystarczy usunąć pliku w nowym commicie: nadal zostanie w historii. Natychmiast zmień sekret, a potem w razie potrzeby wyczyść historię.

Dobre opisy commitów

Dobra historia commitów to dokumentacja dla Ciebie w przyszłości i dla Twojego zespołu:

Pisz krótką pierwszą linię (mniej więcej do 50 znaków) w trybie rozkazującym: „Add avatar upload”, a nie „Added avatars”.
W razie potrzeby dodaj pustą linię i dłuższe wyjaśnienie, dlaczego wprowadzono zmianę.
Każdy commit to jedna logiczna zmiana. Nie mieszaj formatowania, refaktoryzacji i nowych funkcji.

git commit -m "Fix N+1 query on articles index" -m "Preload authors and comments counts to cut page load from 40 to 3 queries."

Dobre praktyki

Commituj często, pushuj regularnie. Małe commity łatwiej przejrzeć, cofnąć i zrozumieć.
Pracuj na gałęziach i scalaj je przez pull requesty z code review.
Rób pull przed rozpoczęciem pracy i utrzymuj swoją gałąź aktualną, aby uniknąć dużych konfliktów.
Nie przepisuj wspólnej historii i unikaj git push --force na wspólnych gałęziach. Jeśli musisz wymusić push własnej gałęzi, użyj --force-with-lease.
Sprawdzaj zmiany przed commitem przez git diff --staged.
Nie trzymaj sekretów w repozytorium i skonfiguruj .gitignore od pierwszego dnia.
Używaj kluczy SSH lub tokenów do uwierzytelniania w zdalnych repozytoriach.

Jak odpowiedzieć na pytanie „Czy znasz Gita?” na rozmowie rekrutacyjnej

Samo „tak” nie wystarczy. Mocna odpowiedź pokazuje, że rozumiesz koncepcje, a nie tylko znasz kilka poleceń. Na przykład: wyjaśnij, że Git to rozproszony system kontroli wersji, opisz trzy obszary i gałęzie, opowiedz o sposobie pracy w Twoim zespole (gałęzie zadań, pull requesty, code review), wyjaśnij różnicę między merge a rebase i podaj przykład, jak rozwiązałeś konflikt lub odzyskałeś utraconą pracę przez git reflog. Prawdziwe przykłady z własnego doświadczenia zawsze przekonują bardziej niż definicje.

Podsumowanie

Git to podstawowe narzędzie każdego programisty. Przechowuje historię projektu, pozwala bezpiecznie eksperymentować na gałęziach i umożliwia pracę zespołową. Poznaj podstawowe polecenia, zrozum, jak działają commity, gałęzie i poczekalnia, naucz się cofać błędy i stosuj dobre praktyki dotyczące commitów i sekretów. Wtedy Git przestanie budzić strach i stanie się niezawodną siatką bezpieczeństwa dla Twojego kodu.

Wstecz