25 najczęstszych pytań i odpowiedzi o Git na rozmowie kwalifikacyjnej — dla każdego poziomu

Podstawowe pytania o Git

Jeśli dopiero zaczynasz z Gitem, część podstawowych pytań może dotyczyć koncepcji i zastosowań dla początkujących. Jeśli chcesz je odświeżyć, zajrzyj do kursu DataCamp Introduction to Git.

Czym jest repozytorium Git?

Repozytorium Git przechowuje pliki projektu i historię zmian, umożliwiając kontrolę wersji poprzez śledzenie modyfikacji w czasie. Może znajdować się lokalnie w folderze na twoim urządzeniu lub na platformie online, takiej jak GitHub. Dzięki temu użytkownicy mogą współpracować, wracać do poprzednich wersji i sprawnie zarządzać rozwojem projektu za pomocą poleceń takich jak commit, push i pull.

Jak działa Git?

Git rejestruje zmiany w plikach i katalogach projektu, zapisując migawki jego ewoluującego stanu. Użytkownicy mogą nadzorować modyfikacje, tworzyć gałęzie do równoległego rozwoju, scalać gałęzie i w razie potrzeby wracać do poprzednich stanów. Git ułatwia współpracę i zapewnia skuteczną kontrolę wersji w przedsięwzięciach programistycznych.

Czym jest git add?

Polecenie git add służy do dodawania zmian do stanu „staged”, aby uwzględnić je w następnym commicie. Przygotowuje modyfikacje, dodania lub usunięcia plików w katalogu roboczym, oznaczając je do włączenia w nadchodzącej migawce commita. Zwróć uwagę, że to polecenie nie wykonuje commita — jedynie przygotowuje zmiany do stage’u.

Czym jest git push?

Polecenie git push służy do przesyłania zawartości lokalnego repozytorium do repozytorium zdalnego. Przenosi zatwierdzone zmiany z repozytorium lokalnego do zdalnego, zwykle na serwerze takim jak GitHub czy GitLab. To polecenie umożliwia współpracę, pozwalając użytkownikom dzielić się zmianami z innymi w tym samym projekcie.

Więcej o git push i pull znajdziesz w osobnym poradniku.

Czym jest git status?

Polecenie git status wyświetla bieżący stan repozytorium. Informuje, które pliki zostały zmodyfikowane, które są w stanie staged do następnego commita, a które są nieśledzone. Pomaga śledzić postępy pracy i zidentyfikować zmiany wymagające zatwierdzenia lub dodania do stage’u.

Czym jest commit w Git?

Commit to migawka zmian wprowadzonych w plikach repozytorium w określonym momencie. Zatwierdzając zmiany w Git, zapisujesz aktualny stan plików i możesz dodać opisowy komunikat wyjaśniający wprowadzone modyfikacje (co jest zalecane).

Każdy commit tworzy unikalny identyfikator, co pozwala śledzić historię zmian w repozytorium. Commity odgrywają kluczową rolę w kontroli wersji, umożliwiając powrót do poprzednich stanów projektu, przegląd historii zmian oraz współpracę poprzez udostępnianie aktualizacji.

Zobacz ściągę do Gita od DataCamp, która pomoże ci przygotować się do rozmowy

Czym jest tworzenie gałęzi (branching) w Git?

Branching to praktyka odgałęzienia od głównej linii rozwoju (zwykle nazywanej main, dawniej master), aby pracować nad nowymi funkcjami, poprawkami lub eksperymentami bez wpływu na główną bazę kodu. Pozwala to na współistnienie wielu równoległych linii rozwoju w tym samym repozytorium.

Każda gałąź reprezentuje osobną linię rozwoju z własnym zestawem commitów, dzięki czemu deweloperzy mogą równolegle pracować nad różnymi funkcjami lub poprawkami. Branching ułatwia współpracę, eksperymentowanie i organizację w projekcie, ponieważ zmiany wprowadzone w danej gałęzi można scalić z główną bazą kodu po ich ukończeniu i przetestowaniu.

Czym jest konflikt w Git?

Konflikty pojawiają się, gdy różni współautorzy wprowadzają sprzeczne zmiany w tej samej części pliku lub plików, zwykle podczas scalania (merge) lub rebase’u. Git nie może automatycznie rozwiązać takich rozbieżności i wymaga ręcznej interwencji użytkownika.

Aby rozwiązać konflikt, otwórz dany plik — Git oznaczy kolizyjne fragmenty znacznikami <<<<<<<, ======= i >>>>>>>. Edytuj plik, zachowując właściwą wersję i usuwając znaczniki, a następnie:

git add <resolved-file>
git commit

Czym jest merge w Git?

Scalanie (merge) to podstawowa operacja w Git, która ułatwia współpracę i integrację zmian z różnych gałęzi w projekcie. Innymi słowy, merge to proces łączenia zmian z różnych gałęzi w jedną, zwykle główną (np. master lub main).

Scalanie integruje zmiany z jednej gałęzi z inną, tworząc nowy commit łączący historie obu gałęzi. Więcej o rozwiązywaniu konfliktów scalania w Git znajdziesz w naszym osobnym poradniku.

Średnio zaawansowane pytania o Git

Czym jest zdalne repozytorium (remote) w Git?

Remote to repozytorium hostowane na serwerze lub innym komputerze, służące do współpracy i udostępniania kodu innym. Stanowi scentralizowane miejsce, do którego deweloperzy mogą wypychać (push) lokalne zmiany i skąd mogą pobierać (pull) zmiany wprowadzone przez innych.

Remoty zwykle konfiguruje się na platformach takich jak GitHub, GitLab czy Bitbucket. Umożliwiają one rozproszony rozwój i ułatwiają pracę zespołową, zapewniając wspólne miejsce do przechowywania i synchronizacji kodu projektu między wieloma współautorami.

Jak cofnąć commit, który został już wypchnięty i upubliczniony?

Możesz użyć polecenia git revert <commit-hash>, aby cofnąć commit, który został już wypchnięty i upubliczniony.

Kroki postępowania:

1. Zidentyfikuj commit do cofnięcia, znajdując jego hash. Możesz to zrobić za pomocą git log, aby przejrzeć historię commitów i znaleźć odpowiedni hash.

2. Mając hash, użyj polecenia git revert z hashem commita, aby utworzyć nowy commit, który odwróci zmiany wprowadzone przez wskazany commit. Na przykład:

git revert <commit-hash>

3. Git otworzy edytor tekstu, aby utworzyć komunikat commita cofającego. W razie potrzeby możesz go edytować, a następnie zapisać i zamknąć edytor.

4. Po zapisaniu komunikatu Git utworzy nowy commit, który skutecznie odwróci zmiany wprowadzone przez wskazany commit. Ten nowy commit zostanie dodany do historii, efektywnie cofając zmiany oryginalnego commita.

5. Na koniec wypchnij nowy commit do zdalnego repozytorium, aby upublicznić cofnięcie, używając polecenia:

git push origin <branch-name> 

Użycie git revert tworzy nowy commit odwracający zmiany oryginalnego commita, bez modyfikowania historii. To podejście jest bezpieczniejsze niż git reset lub git amend, które mogą zmieniać historię i powodować problemy dla współpracowników, którzy już pobrali te zmiany.

Czym jest git stash?

git stash to polecenie, które tymczasowo odkłada zmiany w katalogu roboczym, które nie są gotowe do zatwierdzenia. Pozwala zapisać modyfikacje bez commitowania ich do repozytorium.

Stash jest przydatny przy przełączaniu gałęzi, gdy nie chcesz robić commita ani stracić zmian. Później możesz zastosować odłożone zmiany do katalogu roboczego lub „wyciągnąć” je ze stosu, aby kontynuować pracę.

Czym jest git reflog?

git reflog to polecenie do podglądu dzienników referencji, które rejestrują zmiany wskaźnika HEAD i historię commitów, które były checkoutowane w repozytorium. Zapewnia chronologiczną listę ostatnich działań w repozytorium, w tym commitów, checkoutów, merge’y i resetów.

Reflog jest pomocny przy odzyskiwaniu utraconych commitów lub gałęzi oraz w zrozumieniu sekwencji działań wykonanych w repozytorium.

Jak sprawić, by istniejąca gałąź Git śledziła gałąź zdalną?

Aby ustawić śledzenie gałęzi zdalnej przez istniejącą gałąź, użyj polecenia git branch z opcją --set-upstream-to lub -u, a następnie podaj nazwę zdalnej gałęzi.

Składnia wygląda następująco:

git branch --set-upstream-to=<remote-name>/<branch-name>

albo

git branch -u <remote-name>/<branch-name>

Zaawansowane pytania o Git

Jak zarządzać wieloma konfiguracjami dla różnych projektów w Git?

Aby obsłużyć różne konfiguracje, używaj polecenia git config wraz z flagami --global, --system lub --local, aby dostosować ustawienia na odpowiednich poziomach. Alternatywnie zastosuj includeIf w konfiguracji Gita, aby dołączać określone ustawienia w zależności od ścieżki repozytorium.

Jak obsługiwać duże pliki w Git?

Praca z dużymi plikami w Git może być wyzwaniem ze względu na wpływ na rozmiar repozytorium i wydajność. Użyj Git LFS, aby przechowywać duże pliki poza repozytorium Git, a w repozytorium trzymać jedynie lekkie wskaźniki do nich. To zmniejsza rozmiar repozytorium i poprawia wydajność. Git LFS obsługuje różnych dostawców pamięci i bezproblemowo integruje się z przepływami pracy w Git.

Do czego służy git submodule i jak go zaktualizować?

Polecenie git submodule służy do zarządzania zewnętrznymi zależnościami w repozytorium Git. Pozwala dołączać zewnętrzne repozytoria jako submoduły w głównym repozytorium. To przydatne, gdy chcesz włączyć kod ze źródeł zewnętrznych, zachowując go oddzielnie od głównej bazy kodu projektu.

Aby zaktualizować submoduł w Git, wykonaj następujące kroki:

1. Przejdź do katalogu submodułu w obrębie głównego repozytorium.

2. Użyj git fetch, aby pobrać najnowsze zmiany ze zdalnego repozytorium submodułu.

3. Jeśli chcesz zaktualizować do najnowszego commita na gałęzi śledzonej przez submoduł, użyj git pull.

4. Alternatywnie, aby przejść do konkretnego commita lub gałęzi, użyj git checkout z odpowiednim hashem lub nazwą gałęzi.

5. Po zaktualizowaniu submodułu do pożądanego stanu, zatwierdź zmiany w głównym repozytorium, aby odzwierciedlić zaktualizowany stan submodułu.

Czym jest git cherry-pick i kiedy go używać?

git cherry-pick pozwala zastosować konkretny commit z jednej gałęzi na innej, bez scalania całej gałęzi.

git cherry-pick <commit-hash>

Przydaje się też, gdy commit przypadkiem trafił do złej gałęzi: możesz przenieść go na właściwą, a następnie odwrócić w miejscu, w którym nie powinien się znaleźć.

Czym jest git bisect i do czego służy?

git bisect to narzędzie do debugowania, które wykorzystuje wyszukiwanie binarne do znalezienia konkretnego commita, który wprowadził błąd. Zamiast ręcznie przełączać commity jeden po drugim, wskazujesz Gitowi, który commit jest „dobry” (bez błędu), a który „zły” (z błędem), a Git będzie checkoutować pośrednie commity, za każdym razem zmniejszając zakres poszukiwań o połowę, aż znajdzie winowajcę.

git bisect start
git bisect bad                # current commit has the bug
git bisect good <commit-hash> # this older commit was fine
# Git checks out a commit in between; you test it, then:
git bisect good   # or git bisect bad
# repeat until Git identifies the first bad commit
git bisect reset  # return to original state when done

To znacznie szybsze niż ręczne szukanie w dużych repozytoriach z setkami commitów.

Czym są hooki Gita i jak się ich używa?

Hooki Gita to skrypty uruchamiane automatycznie w określonych momentach przepływu pracy. Znajdują się w katalogu .git/hooks/ repozytorium i mogą być pisane w dowolnym języku skryptowym.

Wyróżniamy dwa typy:

• Hooki po stronie klienta działają lokalnie — np. pre-commit (uruchamia się przed utworzeniem commita) lub commit-msg (waliduje format komunikatu commita).

• Hooki po stronie serwera działają na serwerze zdalnym — np. pre-receive (uruchamia się przed przyjęciem wypchniętych commitów).

Częsty przypadek użycia to hook pre-commit, który automatycznie uruchamia linter lub testy, zanim pozwoli na commit. To egzekwuje standardy jakości kodu w zespole.

Pamiętaj, że hooki nie są kopiowane przy klonowaniu repozytorium, więc zespoły, które na nich polegają, zwykle udostępniają je przez osobny skrypt lub narzędzie takie jak pre-commit (pakiet Pythona).

Pytania o często mylone pojęcia w Git

Jaka jest różnica między git fetch a git pull?

Główna różnica między git fetch a git pull dotyczy ich działania i sposobu aktualizacji repozytorium lokalnego.

Polecenie git fetch pobiera zmiany ze zdalnego repozytorium do lokalnego. Aktualizuje gałęzie śledzące zdalne (np. origin/master) w repozytorium lokalnym, aby odzwierciedlały stan repozytorium zdalnego, ale nie aktualizuje katalogu roboczego ani nie scala zmian z bieżącą gałęzią. Oznacza to, że po fetch możesz przejrzeć zmiany ze zdalnego repozytorium bez wpływu na lokalną pracę.

Polecenie git pull również pobiera zmiany ze zdalnego repozytorium, ale idzie krok dalej: pobiera zmiany i od razu scala je z bieżącą gałęzią w jednym kroku. W praktyce wykonuje git fetch, a następnie git merge, aby włączyć zmiany ze zdalnego repozytorium do aktualnej gałęzi.

Co robi git reset?

Polecenie git reset resetuje bieżący HEAD do wskazanego stanu. Może służyć do cofania zmian, usuwania plików ze stage’u lub przenoszenia wskaźnika HEAD do innego commita. Wyróżnia się trzy główne tryby git reset:

• --soft: Resetuje wskaźnik HEAD do konkretnego commita, ale utrzymuje zmiany na stage’u. Pliki pozostają zmodyfikowane w katalogu roboczym, co pozwala je ponownie zatwierdzić.

• --mixed: Resetuje HEAD do konkretnego commita, usuwając zmiany ze stage’u. Pliki pozostają zmodyfikowane w katalogu roboczym, ale nie są już przygotowane do zatwierdzenia.

• --hard: Resetuje HEAD do konkretnego commita, odrzucając wszystkie zmiany w katalogu roboczym i obszarze stage. Używaj ostrożnie — trwale usuwa niezatwierdzone zmiany.

Ważne: Nigdy nie używaj git reset --hard na commitach, które zostały już wypchnięte do współdzielonej zdalnej gałęzi. Przepisuje to historię i spowoduje poważne problemy dla osób, które już pobrały te commity. Dla commitów publicznych używaj zamiast tego git revert.

Jakie ma znaczenie git push --force-with-lease w porównaniu z git push --force?

Polecenie git push --force-with-lease to ostrożniejsze podejście do wymuszonego wypychania zmian do zdalnego repozytorium niż git push --force, ponieważ zapobiega przypadkowemu nadpisaniu zmian wprowadzonych przez innych na zdalnym repozytorium.

Używając git push --force, wymuszasz wypchnięcie swoich zmian do zdalnego repozytorium niezależnie od tego, czy ktoś zaktualizował je od czasu twojego ostatniego fetch. To może prowadzić do niezamierzonej utraty pracy innych deweloperów.

Z kolei git push --force-with-lease jest bezpieczniejsze. Sprawdza, czy gałąź zdalna, do której wypychasz, została zaktualizowana przez innych od twojego ostatniego fetch. Jeśli tak, push zostanie odrzucony, co zapobiega niezamierzonemu nadpisaniu cudzych zmian.

Czym jest git rebase i czym różni się od git merge?

Zarówno git rebase, jak i git merge integrują zmiany z jednej gałęzi do innej, ale robią to w różny sposób.

• git merge łączy historie dwóch gałęzi, tworząc nowy „commit scalający”. Zachowuje to pełną historię rozgałęzień i ponownego scalenia, co bywa przydatne dla przejrzystości zespołowej i audytów.

• git rebase przenosi (odtwarza) commity z jednej gałęzi na szczyt innej, tworząc czystą, liniową historię bez commitów scalających. Ułatwia to czytanie logów, ale przepisuje historię commitów. Stąd złota zasada rebase: nigdy nie rób rebase na gałęzi, nad którą pracują inni.

Jaka jest różnica między git clone a git fork?

Klonowanie tworzy lokalną kopię zdalnego repozytorium na twojej maszynie. Nadal jesteś połączony z tym samym repozytorium i możesz wypychać zmiany (jeśli masz uprawnienia).

git clone https://github.com/user/repo.git

Forkowanie to standardowy workflow przy kontrybuowaniu do projektów open source, gdzie nie masz bezpośredniego prawa zapisu do oryginalnego repozytorium.

Przygotowanie do rozmowy o Git

Zaprezentowanie wiedzy i doświadczenia z Gitem podczas rozmowy jest kluczowe, by pokazać biegłość w narzędziach i procesach kontroli wersji oraz współpracy w zespołach programistycznych.

Oto kilka wskazówek, których warto się trzymać, przygotowując się do rozmowy technicznej, aby skutecznie komunikować swoje umiejętności w Git:

Zrozum fundamenty Gita

Upewnij się, że masz solidne podstawy: repozytoria, branching, merging, commity oraz podstawowe komendy, takie jak pull, push, clone i commit. Ta wiedza będzie fundamentem rozmowy. Warto też dobrze rozumieć podstawowe zasady kontroli wersji i różnice między Gitem a innymi systemami kontroli wersji.

Wreszcie, zapoznaj się z różnymi metodykami pracy z Gitem, takimi jak Git Flow, GitHub Flow i GitLab Flow. Oceń zalety i wady każdego podejścia oraz sytuacje, w których sprawdzają się najlepiej.

Nasz kompletny przewodnik po Gicie to dobre miejsce, by oswoić się z podstawami.

Zdobądź praktyczne doświadczenie

Im częściej używasz Gita, tym lepiej utrwalasz wiedzę. Regularna praktyka zwiększa obycie z poleceniami i procedurami. Staraj się włączać Gita do codziennej pracy. Koniecznie poeksperymentuj z tworzeniem gałęzi, ich scalaniem i rozwiązywaniem konfliktów.

Jeśli nie wiesz, nad jakimi projektami pracować, aby zdobyć praktykę z Gitem, udział w projektach open source na platformach takich jak GitHub to świetny sposób na bezpośrednie poznanie narzędzi i workflowów branżowych.

Poznaj typowe problemy i sposoby ich rozwiązywania

Podczas pracy z Gitem problemy są nieuniknione. Do typowych należą konflikty merge, stan „detached HEAD”, cofanie zmian czy odzyskiwanie utraconych commitów. Diagnozowanie problemów w Git rozwija umiejętności debugowania i pogłębia zrozumienie mechanizmów Gita.

Aktywnie rozwiązując problemy i analizując komunikaty błędów, zyskasz wgląd w wewnętrzne działanie Gita i rozwiniesz biegłość w sprawnym identyfikowaniu oraz usuwaniu usterek. Takie proaktywne podejście ogranicza ryzyko i buduje pewność siebie oraz kompetencje w zarządzaniu przepływami kontroli wersji.

Ćwicz próbne rozmowy

Udział w próbnych rozmowach pozwala zidentyfikować słabsze obszary wiedzy o Gicie i umiejętności komunikacyjne, dzięki czemu skuteczniej ukierunkujesz przygotowania.

Dodatkowo próbne rozmowy dają cenne możliwości szlifowania umiejętności rozwiązywania problemów poprzez realistyczne scenariusze związane z Gitem i zadania kodujące. Ta praktyka w działaniu buduje pewność w korzystaniu z Gita i ułatwia klarowne artykułowanie myśli w trakcie rozmowy.

Zakończenie

Git to potężny system kontroli wersji, powszechnie używany w rozwoju oprogramowania do zarządzania zmianami w kodzie, współpracy i utrzymywania historii projektu. Znajomość Gita jest kluczowa na rozmowach technicznych — pokazuje biegłość w niezbędnych narzędziach i workflowach, umiejętność współpracy oraz sprawne zarządzanie kodem w środowiskach zespołowych.

Zrozumienie koncepcji i poleceń Gita umożliwia efektywne praktyki kontroli wersji, zapewnia integralność kodu, ciągłość projektu i usprawnione procesy wytwórcze. Wiedza o Gicie jest więc nieoceniona dla początkujących inżynierów oprogramowania i deweloperów, którzy przygotowują się do rozmów technicznych i dążą do udanych karier.

Aby uczyć się dalej, sprawdź poniższe zasoby:

• Czym jest Git? — Kompletny przewodnik po Gicie
• GitHub i Git — poradnik dla początkujących
• GitHub Concepts
• Kompletna ściąga do Gita