Pytania rekrutacyjne Git

52 pytań — 20 odpowiedzi dostępnych od razu

Git jest częstym tematem rozmów technicznych, bo rekruterzy pytają zarówno o codzienną pracę, jak i rozwiązywanie konfliktów czy analizę historii. Darmowy podgląd zawiera przykładowe pytania z puli 52 zagadnień.

W fiszkach znajdziesz podstawowe operacje, branching i merging, pracę z repozytoriami zdalnymi oraz historią commitów. To szybka powtórka dla programistów, którzy chcą pewniej wyjaśniać swoje decyzje w zespole.

← Powrót do wszystkich pytań

Systemy rozproszone 52 Wzorce architektoniczne 47 Programowanie funkcyjne 43 Architektura oprogramowania 107

Darmowy start

Pierwsze 20 odpowiedzi są dostępne od razu

Przeglądaj pełną listę 52 pytań. Pełne odpowiedzi, przykłady kodu i materiały do nauki odblokujesz w panelu.

Odblokuj 32 odpowiedzi

Podstawy Git

1. Czym jest Git i dlaczego się go używa?

Czym jest Git i dlaczego się go używa?

Git to rozproszony system kontroli wersji, umożliwiający śledzenie zmian w kodzie źródłowym oraz współpracę wielu osób nad jednym projektem. Dzięki jego architekturze rozproszonej każdy klon repozytorium zawiera pełną historię zmian, co przekłada się na większą niezależność od głównego serwera (w przeciwieństwie do scentralizowanych systemów) oraz ułatwia pracę w trybie offline.

Najważniejsze cechy Gita:

Rozproszona architektura.
Wydajność i efektywne zarządzanie historią.
Łatwość tworzenia i scalania gałęzi (branchy).
Szerokie wsparcie społeczności i bogaty ekosystem narzędzi.

Materiały

2. Czym jest HEAD w Git?

Czym jest HEAD w Git?

HEAD w Git to wskaźnik wskazujący na aktualnie aktywny commit (tj. najnowszy stan w bieżącej gałęzi). Zazwyczaj HEAD odnosi się do końca gałęzi, nad którą pracujesz – np. master czy main – choć można go również skierować na konkretny commit (tzw. detached HEAD). Z punktu widzenia Gita, HEAD stanowi bieżącą wersję kodu, od której wykonywane są operacje takie jak commit, merge czy rebase. Gdy wykonasz:

git checkout <nazwa_gałęzi>

HEAD przenosi się na początek wybranej gałęzi. Jeśli przełączysz się bezpośrednio na commit, Git wchodzi w stan detached HEAD, co oznacza, że HEAD nie wskazuje na żadną gałąź, a jedynie na dany commit.

Materiały

3. Czym Git różni się od innych systemów kontroli wersji, takich jak SVN czy Mercurial?

Czym Git różni się od innych systemów kontroli wersji, takich jak SVN czy Mercurial?

Rozproszony model
- W Git każdy klon repozytorium zawiera pełną historię projektu. SVN to system scentralizowany, w którym klienci mają najczęściej dostęp tylko do potrzebnej części historii. Mercurial, podobnie jak Git, również ma charakter rozproszony, ale Git jest bardziej rozpowszechniony i ma obszerniejszy ekosystem narzędzi.
Sposób zarządzania gałęziami
- W Git tworzenie i łączenie gałęzi (branchy) jest lekkie i szybkie. W SVN praca na gałęziach bywa bardziej obciążająca, gdyż system został zaprojektowany w architekturze scentralizowanej. Mercurial też obsługuje gałęzie, ale Git uchodzi za bardziej elastyczny w tym zakresie (np. git rebase).
Historia i praca offline
- Git pozwala na wystawianie commitów oraz przeglądanie historii w trybie offline, ponieważ cały repozytorium znajduje się lokalnie. W systemach scentralizowanych (SVN) pewne operacje wymagają bezpośredniej komunikacji z serwerem.
Społeczność i wsparcie
- Git cieszy się bardzo dużą popularnością, co przekłada się na liczne narzędzia, wtyczki i integracje wspierające użytkowników.

Podsumowujac:

Kryterium	Git	SVN	Mercurial
Model	Rozproszony – pełna historia w każdym klonie	Scentralizowany – dostęp zazwyczaj zależny od serwera	Rozproszony, jednak mniej popularny niż Git
Gałęzie (branching)	Szybkie i łatwe, duża elastyczność (np. `git rebase`)	Bardziej złożone, większy nakład pracy	Obsługuje gałęzie, lecz mniejsza elastyczność w porównaniu z Gitem
Praca offline	Pełna kopia repozytorium lokalnie, nie wymaga ciągłego dostępu do sieci	Znacznie ograniczona – większość operacji wymaga serwera	Możliwa praca offline, podobnie jak w Git
Popularność i ekosystem	Bardzo szerokie wsparcie, bogata społeczność i kasa narzędzi	Używany głównie w starszych lub wewnętrznych projektach	Mniejsza społeczność i ekosystem w porównaniu do Gita, ale nadal rozwijany

Materiały

4. Czym jest repozytorium w Git?

Czym jest repozytorium w Git?

Repozytorium (ang. repository) w Git to główny katalog projektu zawierający całą historię zmian i strukturę plików. Repozytorium przechowuje metadane Gita w ukrytym katalogu .git, w tym informacje o commitach, gałęziach, tagach czy referencjach.

Kluczowe elementy repozytorium:

.git – ukryty katalog, w którym znajdują się wszystkie dane i obiekty Gita (commity, gałęzie itp.).
Working Directory (obszar roboczy) – aktualny stan plików, nad którymi użytkownik pracuje.
Staging Area (index) – obszar tymczasowy, który zapisuje zmiany przed utworzeniem commitu.

Materiały

5. Jak zainicjować nowe repozytorium Git w projekcie?

Jak zainicjować nowe repozytorium Git w projekcie?

Aby utworzyć repozytorium Git w istniejącym katalogu projektu, należy wykonać:

git init

Polecenie git init tworzy ukryty folder .git z metadanymi systemu kontroli wersji i przekształca bieżący katalog w lokalne repozytorium Git. Następnie można dodać pliki i wysłać pierwszy commit:

git add .
git commit -m "Początkowy commit"

Materiały

Pro Git Book: Inicjalizacja projektu

6. Czy możesz wyjaśnić koncepcję commitu w Git?

Czy możesz wyjaśnić koncepcję `commitu` w Git?

Commit to zarejestrowanie stanu projektu w repozytorium na konkretnym etapie prac. Każdy commit zawiera:

Snapshota wszystkich śledzonych plików w danym momencie.
Identyfikator SHA-1 (unika się wpadek typu collision dzięki 40-znakowemu skrótowi).
Metadane: autora, czas utworzenia, komunikat opisujący zmiany (commit message), rodziców (lub rodzica), co pozwala śledzić historię.

Przykładowa sekwencja tworzenia commitu:

# Dodanie plików do obszaru przygotowania (staging)
git add [nazwa_pliku]

# Zarejestrowanie commitu
git commit -m "Krótki opis zmian"

Materiały

Podstawowe operacje

7. Jaka jest różnica między poleceniami git add a git commit?

Jaka jest różnica między poleceniami `git add` a `git commit`?

git add przenosi zmiany z obszaru roboczego (working directory) do obszaru indeksu (staging area). Oznacza to, że pliki dodane przy pomocy git add zostaną uwzględnione w kolejnym commicie.
git commit tworzy nowy punkt kontrolny (commit) w historii repozytorium, zapisując stan zmian, które znajdują się aktualnie w obszarze indeksu.

Porównanie w praktyce

Dokonujemy edycji plików.
Używamy git add, aby wskazać, które zmiany mają znaleźć się w commicie.
Używamy git commit, aby utrwalić zmiany w historii repozytorium.

Materiały

8. Jak sprawdzić stan obszaru roboczego i indeksu?

Jak sprawdzić stan obszaru roboczego i indeksu?

W tym celu wykorzystuje się polecenie:

git status

Polecenie git status wyświetla:

Informację o aktualnej gałęzi (branch).
Listę plików zmodyfikowanych, ale niezapisanych (unstaged).
Listę plików w obszarze indeksu (staged).
Ewentualne komunikaty o plikach nieśledzonych (untracked).

Materiały

9. Jak odrzucić lokalne zmiany w pliku w obszarze roboczym?

Jak odrzucić lokalne zmiany w pliku w obszarze roboczym?

Aby przywrócić plik do stanu ostatniego commitu (czyli odrzucić wszystkie lokalne modyfikacje), możesz użyć:

git checkout -- <nazwa_pliku>

lub w nowszych wersjach Gita:

git restore <nazwa_pliku>

Powyższe polecenie przywraca plik ze stanu zapisanego w historii. W rezultacie wszystkie niezacommitowane zmiany zostaną utracone.

Uwaga

Jeśli chcesz przywrócić całą strukturę do stanu z ostatniego commitu, możesz użyć git restore . (w nowszych wersjach Git), jednak pamiętaj, że spowoduje to skasowanie wszystkich lokalnych zmian, których nie zapisano we wcześniejszych commitach.

Materiały

10. Jakie są różne sposoby na cofnięcie lub wycofanie commitu?

Jakie są różne sposoby na cofnięcie lub wycofanie commitu?

git revert <identyfikator_commitu>
- Tworzy nowy commit, który wprowadza odwrotne zmiany do wybranego commitu. Historia pozostaje nienaruszona, co jest polecane w projektach z repozytorium współdzielonym.
git reset
- Modyfikuje wskaźnik aktualnej gałęzi na inny commit, zmieniając historię.
- Może działać w trzech trybach:
  - --soft – zachowuje zmiany w obszarze indeksu (staging).
  - --mixed – (domyślne) zachowuje zmiany w obszarze roboczym, ale usuwa je z indeksu.
  - --hard – całkowicie usuwa zmiany zrobione po wybranym commicie.
git checkout / git restore
- Pozwala przywrócić pojedyncze pliki do stanu z wybranego commitu, nie dotykając całej historii.
git revert -n (lub --no-commit)
- Przydatne do łączenia wielu odwróceń w jeden commit.

Materiały

11. Jak porównać różnice pomiędzy dwoma commitami, branchami lub plikami?

Jak porównać różnice pomiędzy dwoma commitami, branchami lub plikami?

Do wyświetlenia różnic służy polecenie:

git diff

Porównywanie dwóch commitów

git diff <commit1> <commit2>

Polecenie wypisze różnice w plikach między wskazanymi commitami.

Porównywanie gałęzi

git diff <branch1> <branch2>

Wyświetla różnice między stanami dwóch branchy.

Porównywanie pliku między branchami

git diff <branch1> <branch2> -- <nazwa_pliku>

Ogranicza różnice do zadanego pliku.

Materiały

Dodatkowe materiały

Branching i Merging

12. Czym jest gałąź (branch) w Git i dlaczego korzystanie z gałęzi jest przydatne?

Czym jest gałąź (branch) w Git i dlaczego korzystanie z gałęzi jest przydatne?

Gałąź (branch) w Git reprezentuje niezależną linię rozwoju w obrębie tego samego repozytorium. Umożliwia tworzenie nowych funkcjonalności, poprawek lub eksperymentów bez ingerowania w główną (stabilną) gałąź projektu, np. main czy master. Dzięki temu praca kilku osób nad różnymi funkcjonalnościami przebiega równolegle, a scalanie zmian staje się prostsze.

Przydatne materiały:

13. Jak utworzyć nową gałąź i jak się na nią przełączyć?

Jak utworzyć nową gałąź i jak się na nią przełączyć?

Aby utworzyć nową gałąź i jednocześnie się na nią przełączyć, możesz użyć polecenia:

git checkout -b [nazwa_gałęzi]

Jeśli najpierw chcesz utworzyć gałąź, a następnie się na nią przełączyć, wykonaj osobno:

git branch [nazwa_gałęzi]
git checkout [nazwa_gałęzi]

Dzięki temu praca nad nową funkcjonalnością jest odseparowana od głównej gałęzi, co pozwala na bezpieczne wprowadzanie zmian.

Przydatne materiały:

14. Czym jest merge i jak działa w Git?

Czym jest merge i jak działa w Git?

Merge (scalanie) łączy zmiany wprowadzone w jednej gałęzi z inną (np. z gałęzią główną). Gdy wykonujesz git merge <nazwa_gałęzi>, Git próbuje zintegrować wszystkie commity z docelowej gałęzi do bieżącej. Może to być automatyczne, jeśli nie ma konfliktów, albo wymagać ręcznego rozwiązania, gdy te same fragmenty kodu zostały edytowane w obu gałęziach.

Przydatne materiały:

15. Na czym polega różnica między merge a rebase?

Na czym polega różnica między merge a rebase?

Merge tworzy tzw. commit scalający (merge commit). W historii pojawia się rozgałęzienie, a następnie scalenie w jednym punkcie.
Rebase przenosi (reaplikuje) commity z jednej gałęzi na szczyt innej. W efekcie historia wygląda liniowo, bez dodatkowego commitu scalającego.

Z punktu widzenia pracy zespołowej merge bywa prostszy i bezpieczniejszy, natomiast rebase pozwala na estetyczną, uporządkowaną historię – wymaga jednak ostrożności, szczególnie w repozytoriach współdzielonych.

Przydatne materiały:

16. Jak radzić sobie z konfliktami podczas scalania?

Jak radzić sobie z konfliktami podczas scalania?

Zidentyfikuj konflikt: Podczas git merge lub git rebase, Git zaznaczy w kolidujących plikach fragmenty kodu wymagające ręcznego rozwiązania.
Rozwiąż konflikt: Edytuj pliki, usuwając znaczniki konfliktu (<<<<<, >>>>> itp.), a następnie wybierz lub połącz odpowiednie fragmenty kodu.
Zatwierdź rozwiązanie: Po dokonaniu zmian wykonaj

   git add <naprawiony_plik>
   git commit

w przypadku merge, lub

   git rebase --continue

w przypadku rebase.

Przydatne materiały:

Repozytoria zdalne

17. Jak dodać zdalne repozytorium do lokalnego repozytorium Git?

Jak dodać zdalne repozytorium do lokalnego repozytorium Git?

Aby dodać zdalne repozytorium do już istniejącego lokalnego repozytorium, możesz użyć komendy:

git remote add <nazwa_aliasu> <adres_URL_repozytorium>

Przykładowo:

git remote add origin https://github.com/użytkownik/moje-repo.git

W ten sposób łączymy alias (np. origin) z konkretnym adresem URL repozytorium na serwerze.

Polecane materiały:

18. Czym różni się git pull od git fetch?

Czym różni się `git pull` od `git fetch`?

git fetch pobiera najnowsze commity i referencje (wskazówki gałęzi, tagi) z repozytorium zdalnego, ale nie scala ich automatycznie z bieżącą gałęzią lokalną. Pozwala to na dokładne przeanalizowanie zmian przed ich zintegrowaniem.
git pull wykonuje git fetch, a następnie automatycznie próbuje scalić (merge) lub w zależności od konfiguracji wykonać rebase z nowo pobranymi zmianami w bieżącej gałęzi.

Polecane materiały:

19. Jak sklonować zdalne repozytorium na lokalną maszynę?

Jak sklonować zdalne repozytorium na lokalną maszynę?

Aby sklonować repozytorium, czyli pobrać jego kopię na lokalną maszynę, wykonujesz:

git clone <adres_URL_repozytorium>

Przykład:

git clone https://github.com/użytkownik/moje-repo.git

Dzięki temu otrzymasz kompletną historię projektu, tworząc na dysku lokalnym nowy katalog z zawartością repozytorium.

Polecane materiały:

Pro Git Book (pl): Klonowanie repozytorium

20. Do czego służy git push?

Do czego służy `git push`?

git push wysyła lokalne commity do repozytorium zdalnego. Jeżeli pracujesz z gałęzią lokalną o nazwie feature-1 i chcesz przesłać ją do gałęzi feature-1 na serwerze, wykonaj:

git push origin feature-1

Dzięki temu zespół będzie miał dostęp do Twoich zmian w repozytorium zdalnym.

Polecane materiały:

Pro Git Book (pl): Praca zdalna – Git Push

21. Jak wygląda uwierzytelnianie (authentication) przy pracy ze zdalnym repozytorium?