Git dla Programistów - Pytania Rekrutacyjne od Podstaw 2026

Git to jeden z tych tematów, które wydają się proste na pierwszy rzut oka, ale szybko okazuje się że większość programistów zna tylko add, commit i push. Problem w tym, że rekruterzy szukają czegoś więcej. Chcą wiedzieć czy rozumiesz jak Git działa pod spodem, czy potrafisz rozwiązać konflikt scalania bez paniki, i czy wiesz kiedy użyć rebase zamiast merge.

W tym artykule przeprowadzę Cię przez najczęstsze pytania rekrutacyjne dotyczące Git, od podstaw po zaawansowane koncepcje. Pokażę Ci jak odpowiadać w sposób, który zrobi wrażenie na rekruterze.

Czym Jest Git i Dlaczego Jest Tak Ważny

Odpowiedź w 30 sekund

Kiedy rekruter pyta "Czym jest Git?", odpowiedz tak:

Git to rozproszony system kontroli wersji. Każdy klon repozytorium zawiera pełną historię projektu, co oznacza że mogę pracować offline i nie jestem zależny od centralnego serwera. Git wyróżnia się wydajnością przy tworzeniu gałęzi i szerokim wsparciem narzędzi.

Zatrzymaj się i poczekaj na follow-up.

Odpowiedź w 2 minuty

Jeśli rekruter chce więcej szczegółów:

Git powstał w 2005 roku, stworzony przez Linusa Torvaldsa do zarządzania kodem jądra Linuxa. W przeciwieństwie do scentralizowanych systemów jak SVN, Git jest rozproszony, co oznacza że każdy developer ma pełną kopię repozytorium.

Najważniejsze cechy to:

• Rozproszona architektura eliminująca pojedynczy punkt awarii
• Szybkie operacje lokalne bez komunikacji z serwerem
• Lekkie gałęzie umożliwiające eksperymentowanie bez ryzyka
• Integralność danych dzięki hashom SHA-1

W praktyce Git używamy do śledzenia historii zmian, współpracy zespołowej, code review przez pull requesty, i zarządzania różnymi wersjami oprogramowania.

HEAD w Git - Fundamentalne Pojęcie

Rekruterzy lubią pytać o HEAD, bo to pokazuje czy rozumiesz wewnętrzną strukturę Git. HEAD to wskaźnik wskazujący na aktualnie aktywny commit, czyli najnowszy stan w bieżącej gałęzi.

Odpowiedź w 30 sekund

HEAD to wskaźnik pokazujący gdzie aktualnie znajduje się mój obszar roboczy. Zazwyczaj wskazuje na koniec gałęzi jak main czy develop. Kiedy przełączam się na inną gałąź komendą git checkout, HEAD przesuwa się na nową pozycję.

Detached HEAD - Klasyczny Problem

Tu robi się ciekawie. Kiedy zrobisz checkout bezpośrednio na konkretny commit zamiast gałęzi:

git checkout abc1234

Git wchodzi w stan detached HEAD. Oznacza to że HEAD nie wskazuje na żadną gałąź, tylko na konkretny commit. Możesz tu eksperymentować, ale jeśli zrobisz nowe commity i przełączysz się z powrotem na gałąź, te commity zostaną osierocone.

Wzorzec który mi się sprawdził to zawsze tworzenie gałęzi przed rozpoczęciem pracy w detached HEAD:

# Zamiast tego
git checkout abc1234

# Zrób to
git checkout -b eksperyment abc1234

Git Add vs Git Commit - Rozróżnienie Które Musisz Znać

Odpowiedź w 30 sekund

Git add przenosi zmiany z obszaru roboczego do staging area, czyli przygotowuje je do commitu. Git commit zapisuje te zmiany w historii repozytorium. To dwuetapowy proces który daje mi kontrolę nad tym co dokładnie trafi do commitu.

Odpowiedź w 2 minuty

Pokażę na przykładzie jak to działa w praktyce:

# Edytuję dwa pliki
vim user.js
vim config.js

# Sprawdzam status - oba pliki są w stanie "modified"
git status

# Dodaję tylko jeden plik do staging
git add user.js

# Teraz user.js jest "staged", config.js nadal "modified"
git status

# Commit zapisuje tylko zmiany ze staging area
git commit -m "Dodaj walidację użytkownika"

# config.js nadal czeka - mogę go dodać do następnego commitu

To rozdzielenie jest kluczowe dla tworzenia czystej historii. Mogę mieć 10 zmodyfikowanych plików, ale do każdego commitu dodać tylko te które logicznie do siebie pasują.

Praca z Gałęziami - Branching i Merging

Praca z gałęziami to chleb powszedni każdego developera, ale rekruterzy szukają głębszego zrozumienia. Gałąź (branch) w Git reprezentuje niezależną linię rozwoju. Umożliwia tworzenie nowych funkcjonalności bez ingerowania w główną, stabilną gałąź projektu.

Tworzenie i Przełączanie Gałęzi

# Tworzę nową gałąź i od razu się na nią przełączam
git checkout -b feature/nowa-funkcjonalnosc

# Lub w dwóch krokach
git branch feature/nowa-funkcjonalnosc
git checkout feature/nowa-funkcjonalnosc

# Nowszy sposób (Git 2.23+)
git switch -c feature/nowa-funkcjonalnosc

Merge vs Rebase - Pytanie na Które Musisz Znać Odpowiedź

To jedno z najczęstszych pytań rekrutacyjnych. Odpowiedź którą daję kandydatom to:

Odpowiedź w 30 sekund

Merge tworzy commit scalający i zachowuje oryginalną historię z rozgałęzieniami. Rebase przepisuje historię, przenosząc moje commity na szczyt innej gałęzi, co daje liniową historię. Merge jest bezpieczniejszy dla repozytoriów współdzielonych, rebase daje czystszą historię.

Odpowiedź w 2 minuty z przykładami

# Scenariusz: pracuję na feature/auth, main poszło do przodu

# MERGE - zachowuje historię
git checkout main
git merge feature/auth
# Tworzy merge commit, widać rozgałęzienie w historii

# REBASE - przepisuje historię
git checkout feature/auth
git rebase main
# Moje commity są "przeniesione" na szczyt main
# Historia wygląda liniowo, jakbym zaczął od najnowszego main

Kiedy używam czego? Merge gdy pracuję z innymi i chcę zachować kontekst historyczny. Rebase gdy pracuję sam na feature branch i chcę mieć czystą historię przed mergem do main.

Rozwiązywanie Konfliktów - Klasyczny Problem

Konflikty są nieuniknione przy pracy zespołowej. Kandydaci, którzy potrafią spokojnie wyjaśnić proces rozwiązywania konfliktów, robią wrażenie.

# Podczas merge lub rebase Git informuje o konflikcie
# Otwieram plik z konfliktem i widzę:

<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature/nowy-timeout

# Wybieram właściwą wersję lub łączę obie
const timeout = process.env.TIMEOUT || 5000;

# Po rozwiązaniu wszystkich konfliktów
git add plik-z-konfliktem.js

# Dla merge
git commit

# Dla rebase
git rebase --continue

Repozytoria Zdalne - Współpraca z Innymi

Git Fetch vs Git Pull

To pytanie pojawia się praktycznie na każdej rozmowie.

Odpowiedź w 30 sekund

Fetch pobiera zmiany ze zdalnego repozytorium bez scalania ich z moją lokalną gałęzią. Pull robi fetch plus automatycznie merge. Używam fetch gdy chcę najpierw zobaczyć co się zmieniło, pull gdy wiem że chcę od razu zintegrować zmiany.

Odpowiedź w 2 minuty

# Fetch - bezpieczne sprawdzenie co jest nowego
git fetch origin

# Teraz mogę porównać lokalną gałąź ze zdalną
git diff main origin/main

# Jeśli wszystko OK, ręcznie scalam
git merge origin/main

# Pull - robi to samo w jednym kroku
git pull origin main
# Równoważne: git fetch origin && git merge origin/main

# Pull z rebase zamiast merge
git pull --rebase origin main

Wzorzec który mi się sprawdził w zespołach to używanie git fetch rano żeby zobaczyć co się zmieniło w nocy, a git pull gdy aktywnie pracuję nad feature branchem.

Git Push - Wysyłanie Zmian

# Podstawowe wysłanie zmian
git push origin feature/moja-galaz

# Pierwsze wysłanie nowej gałęzi (ustawia upstream)
git push -u origin feature/moja-galaz

# Po -u mogę używać samego git push
git push

Historia Commitów - Zaawansowane Narzędzia

Git Log - Przeglądanie Historii

# Podstawowy log
git log

# Skrócona wersja, jedna linia na commit
git log --oneline

# Z wizualizacją gałęzi
git log --oneline --graph --decorate

# Historia konkretnego pliku
git log --follow -- src/user.js

# Szukanie commitów z konkretnym tekstem
git log --grep="fix bug"

Git Blame - Kto Napisał Ten Kod

Rekruterzy lubią pytać o git blame bo pokazuje czy kandydat kiedykolwiek debugował produkcyjny kod.

# Kto zmienił każdą linię w pliku
git blame src/user.js

# Ignoruj zmiany formatowania (whitespace)
git blame -w src/user.js

# Pokaż konkretne linie
git blame -L 10,20 src/user.js

Git Reflog - Twój Ratunek

Reflog to historia wszystkich zmian HEAD, nawet tych "usuniętych". To ratunek gdy przypadkowo usuniesz commity.

# Pokaż historię ruchów HEAD
git reflog

# Przywróć commit który "zgubiłeś"
git checkout HEAD@{2}
# lub
git reset --hard HEAD@{2}

Różnica między git log a git reflog: log pokazuje historię commitów dostępną przez gałęzie, reflog śledzi każdy ruch HEAD lokalnie, nawet po rebase czy reset.

Zaawansowane Koncepcje - Pytania dla Seniorów

Interactive Rebase - Porządkowanie Historii

# Chcę uporządkować ostatnie 3 commity
git rebase -i HEAD~3

# Otwiera się edytor z listą commitów
pick abc1234 Dodaj funkcję logowania
pick def5678 Popraw literówkę
pick ghi9012 Dodaj testy

# Mogę zmienić na:
pick abc1234 Dodaj funkcję logowania
squash def5678 Popraw literówkę  # Połącz z poprzednim
reword ghi9012 Dodaj testy       # Zmień opis commitu

Możliwe akcje w interactive rebase:

• pick - użyj commitu bez zmian
• reword - zmień opis commitu
• squash - połącz z poprzednim commitem
• fixup - jak squash, ale odrzuć opis
• drop - usuń commit

Cherry-Pick - Przenoszenie Pojedynczych Commitów

# Jestem na main, chcę przenieść jeden commit z feature branch
git cherry-pick abc1234

# Przeniesienie kilku commitów
git cherry-pick abc1234 def5678

# Bez automatycznego commitu (mogę zmodyfikować przed commitem)
git cherry-pick -n abc1234

Kiedy używam cherry-pick? Gdy mam hotfix na develop i chcę go też na production bez mergowania całej gałęzi develop.

Submoduły - Zależności między Repozytoriami

# Dodanie submodułu
git submodule add https://github.com/lib/component.git libs/component

# Po sklonowaniu repo z submodułami
git submodule update --init --recursive

# Aktualizacja submodułu do najnowszej wersji
cd libs/component
git pull origin main
cd ../..
git add libs/component
git commit -m "Aktualizuj submoduł component"

Cofanie Zmian - Reset, Revert, Restore

To często powoduje zamieszanie u kandydatów. Wyjaśnię różnice:

Git Reset - Trzy Tryby

# --soft: Cofnij commit, zachowaj zmiany w staging
git reset --soft HEAD~1

# --mixed (domyślny): Cofnij commit, zachowaj zmiany w working directory
git reset HEAD~1

# --hard: Cofnij commit, usuń wszystkie zmiany (niebezpieczne!)
git reset --hard HEAD~1

Git Revert - Bezpieczne Cofanie

# Stwórz nowy commit odwracający zmiany z abc1234
git revert abc1234

# Revert wielu commitów bez automatycznych commitów
git revert -n abc1234 def5678
git commit -m "Cofam zmiany z abc1234 i def5678"

Kiedy co używać? Reset gdy pracuję lokalnie i chcę przepisać historię. Revert gdy zmiany są już na zdalnym repozytorium i pracują z nimi inni.

Git Restore - Odrzucanie Lokalnych Zmian

# Odrzuć zmiany w pliku (przywróć z ostatniego commitu)
git restore plik.js

# Usuń plik ze staging (przeciwieństwo git add)
git restore --staged plik.js

Bezpieczeństwo i Dobre Praktyki

Gitignore - Co Ignorować

# Pliki środowiskowe (hasła, klucze API)
.env
.env.local
*.pem

# Zależności
node_modules/
vendor/

# Pliki build
dist/
build/
*.log

# Pliki IDE
.idea/
.vscode/
*.swp

Dobre Praktyki Tworzenia Commitów

Rekruterzy doceniają kandydatów, którzy rozumieją znaczenie dobrej historii commitów.

# Dobry commit message
git commit -m "Dodaj walidację emaila w formularzu rejestracji

- Implementacja regex dla formatu email
- Komunikaty błędów w języku polskim
- Testy jednostkowe dla edge cases

Fixes #123"

# Zły commit message
git commit -m "fix"
git commit -m "zmiany"
git commit -m "WIP"

Zasady dobrego commit message:

1. Pierwsza linia do 50 znaków, tryb rozkazujący ("Dodaj" nie "Dodałem")
2. Pusta linia po tytule
3. Opis wyjaśniający "dlaczego" nie "co"
4. Referencje do ticketów/issues

Podpisywanie Commitów - GPG

# Konfiguracja klucza GPG
git config --global user.signingkey KLUCZ_ID

# Commit z podpisem
git commit -S -m "Bezpieczny commit z podpisem GPG"

# Automatyczne podpisywanie wszystkich commitów
git config --global commit.gpgsign true

Wydajność i Optymalizacja

Git GC - Garbage Collection

# Ręczne uruchomienie garbage collection
git gc

# Agresywne czyszczenie (wolniejsze, bardziej dokładne)
git gc --aggressive

Płytki Klon vs Pełny Klon

# Pełny klon - cała historia
git clone https://github.com/user/repo.git

# Płytki klon - tylko ostatnie 10 commitów
git clone --depth 10 https://github.com/user/repo.git

# Przydatne w CI/CD gdy nie potrzebujesz historii

Git LFS - Duże Pliki

# Instalacja Git LFS
git lfs install

# Śledzenie dużych plików
git lfs track "*.psd"
git lfs track "*.zip"

# Nie zapomnij zacommitować .gitattributes
git add .gitattributes
git commit -m "Konfiguruj Git LFS dla dużych plików"

Gitflow - Strategia Pracy z Gałęziami

Gitflow to popularny model pracy który rekruterzy lubią omawiać.

Struktura Gałęzi

main (lub master)     - produkcja, zawsze stabilna
develop               - główna gałąź rozwojowa
feature/*             - nowe funkcjonalności
release/*             - przygotowanie do wydania
hotfix/*              - pilne poprawki produkcyjne

Przykładowy Flow

# Zaczynam nową funkcjonalność
git checkout develop
git checkout -b feature/user-auth

# Pracuję, commituję...
git add .
git commit -m "Implementuj logowanie"

# Kończę feature, merge do develop
git checkout develop
git merge feature/user-auth
git branch -d feature/user-auth

# Przygotowanie release
git checkout -b release/1.0.0
# Testy, poprawki...
git checkout main
git merge release/1.0.0
git tag v1.0.0

# Hotfix produkcyjny
git checkout main
git checkout -b hotfix/critical-bug
# Poprawka...
git checkout main
git merge hotfix/critical-bug
git checkout develop
git merge hotfix/critical-bug

Na Co Rekruterzy Naprawdę Zwracają Uwagę

Po przeprowadzeniu setek rozmów rekrutacyjnych, mogę powiedzieć że sprawdzam:

1. Podstawy - Czy kandydat rozumie różnicę między staging a working directory
2. Rozwiązywanie problemów - Jak radzi sobie z konfliktami i błędami
3. Bezpieczeństwo - Czy wie co nie powinno trafić do repozytorium
4. Współpraca - Czy rozumie pull requesty i code review
5. Historia - Czy dba o czytelność commitów

Kandydaci, którzy potrafią wyjaśnić różnicę między merge a rebase, wiedzą jak użyć interactive rebase, i rozumieją kiedy użyć reset vs revert, wyróżniają się na tle innych.

Praktyka na Koniec

Sprawdź się przed rozmową:

1. Co się stanie po wykonaniu git reset --hard HEAD~3?

2. Masz konflikt podczas rebase. Jakie są Twoje opcje?

3. Jak przeniesiesz jeden konkretny commit z gałęzi feature na hotfix?

4. Jak znajdziesz commit który wprowadził bug, jeśli wiesz że bug nie istniał tydzień temu?

Odpowiedzi:

1. Usuniesz ostatnie 3 commity WRAZ ze wszystkimi zmianami. To nieodwracalne (chyba że użyjesz reflog).
2. Trzy opcje:
   • Rozwiąż konflikt ręcznie, git add, git rebase --continue
   • git rebase --skip - pomiń problematyczny commit
   • git rebase --abort - anuluj cały rebase i wróć do stanu sprzed
3. git cherry-pick SHA_COMMITU na gałęzi hotfix
4. git bisect - binarne przeszukiwanie historii:

   git bisect start
   git bisect bad HEAD
   git bisect good HEAD~50
   # Git wybiera commit do sprawdzenia
   # Testujesz i mówisz: git bisect good/bad
   # Powtarzasz aż znajdzie winowajcę
   git bisect reset

Zobacz też

• Jak Przygotować Się do Rozmowy Technicznej - kompletny plan przygotowania do rekrutacji
• Soft Skills na Rozmowie Rekrutacyjnej - praca zespołowa wymaga znajomości Git

---

Przygotuj Się Jeszcze Lepiej

To tylko część pytań które mogą pojawić się na rozmowie. Nasze fiszki do nauki zawierają ponad 100 pytań z Gita i innych technologii, z odpowiedziami i przykładami kodu.

Zobacz Wszystkie Fiszki dla Programistów →

Lub wypróbuj darmowy podgląd fiszek Git żeby zobaczyć więcej pytań.

---

Napisane przez zespół Flipcards, na podstawie doświadczeń z setek rozmów rekrutacyjnych i ponad 12 lat pracy w branży IT.