Jedną z części rozmowy rekrutacyjnej jest rozmowa techniczna. Często podczas tej części rozmowy rekruter poprosi Cię o opisanie projektów, w których do tej pory brałeś(aś) udział. Warto wtedy opisać czego się nauczyłeś(aś), jakie trudności napotkałeś(aś) oraz jak udało Ci się z nimi uporać. W wielu przypadkach rekruterowi to wystarczy. Gdy jednak nie masz zbyt wiele doświadczenia, to rekruter będzie chciał sprawdzić Twoją wiedzę poprzez serię kilku pytań technicznych.

Część pytań pochodzi z mojego e-booka 106 Pytań Rekrutacyjnych Junior JavaScript Developer, który możesz odebrać, zapisując się na mój mailing. Nie wszystkie pytania zawarte w tym artykule znajdziesz w moim e-booku, więc zachęcam Cię do przeczytania tego wpisu, nawet jeśli planujesz przeczytać e-booka.

Na blogu tematyce pytań technicznych poświęciłem szerszą uwagę w serii wpisów. Zachęcam do sprawdzenia pozostałych artykułów:

• Junior Web Developer – pytania rekrutacyjne cz. 1
• Junior Web Developer – pytania rekrutacyjne cz. 2
• Junior Web Developer – pytania rekrutacyjne cz. 3
• Junior Web Developer – pytania rekrutacyjne cz. 4
• Junior Web Developer – pytania rekrutacyjne cz. 5
• Junior Web Developer – pytania rekrutacyjne – React
• Programista – pytania rekrutacyjne – TypeScript
• Programista – pytania rekrutacyjne – Docker
• Programista – pytania rekrutacyjne – bazy danych

Pytania z tej serii możesz również traktować jako trening i sprawdzenie swoich umiejętności przed rozmową rekrutacyjną.

W tym artykule motywem przewodnim będzie Git, czyli jeden z najpopularniejszych systemów kontroli wersji. Do napisania tego artykułu zainspirowała mnie książka Pro Git autorstwa Scotta Chacona i Bena Strauba, którą polecam zarówno tym osobom, które chcą zacząć przygodę z Gitem, jak i tym znającym już podstawy. Całą listę polecanych przeze mnie książek możesz znaleźć na stronie z polecanymi książkami.

Czym jest Git / czym są systemy kontroli wersji? Do czego je wykorzystujemy?

Pytanie to ma na celu zweryfikowanie czy rozmówca ma jakiekolwiek pojęcie o celu i sposobie działania systemów kontroli wersji. Git jest jednym z najpopularniejszych rozproszonych systemów kontroli wersji (DVCS — Distributed Version Control Systems). Rozproszony system kontroli wersji cechuje się tym, że w przeciwieństwie do scentralizowanych systemów kontroli wersji (CVCS — Centralized Version Control Systems), nie jest potrzebny centralny serwer. Git, a także inne DVCS, mogą być używane całkowicie lokalnie, bez żadnego bytu centralnego. Z kolei same systemy kontroli wersji to narzędzia rozwiązujące kilka istotnych problemów:

1. Przede wszystkim systemy kontroli wersji umożliwiają to, co wskazuje ich nazwa, czyli wersjonowanie projektu. Nie mam tu na myśli jednak wersjonowania rozumianego jako oznaczenie oprogramowania na przykład numerem wersji. Mam tu na myśli możliwość prześledzenia każdej zmiany, która zaistniała w projekcie. Oznacza to również możliwość cofnięcia się do dowolnego poprzedniego stanu projektu.
2. System kontroli wersji pomaga dokumentować zmiany w projekcie. W Gicie podstawowym bytem jest commit, którego elementem składowym jest opis. Na opis może składać się zarówno informacja, co zostało zmienione, ale może zawierać też cel tej zmiany. Bardzo zachęcam do zapoznania się z poradnikiem jak pisać dobre opisy commitów, bo wbrew pozorom nie jest to łatwe zadanie.
3. Dzięki VCS możliwa jest praca nad kilkoma rzeczami jednocześnie i niezależnie od siebie. Do tego celu został stworzony mechanizm gałęzi (branchy). Gałęzie jednocześnie zwiększają wygodę pracy nad projektem w zespołach. Mechanizm gałęzi pozwala na pracę wielu programistów nad tym samym kodem bez przeszkadzania sobie nawzajem.

Jaka jest różnica między Gitem a GitHubem?

Pytanie nieco żartobliwe, ale jego cel jest taki sam jak poprzedniego pytania. Można na nie odpowiedzieć żartobliwie na przykład: „taka jak pomiędzy krzesłem a krzesłem elektrycznym”.

Można także odpowiedzieć całkowicie poważnie. Git, tak jak odpowiedziałem w poprzednim pytaniu, jest systemem kontroli wersji, natomiast GitHub jest platformą zajmującą się hostingiem kodu źródłowego wykorzystującą Gita oraz dostarczającą cały zestaw udogodnień i narzędzi do pracy nad projektem.

Czym jest „bare repository”?

Przy inicjalizacji repozytorium za pomocą polecenia git init można skorzystać z flagi --bare. W konsekwencji takie repozytorium zostanie „nagim” repozytorium, czyli niezawierającym faktycznych kopii plików / kodu źródłowego a jedynie historię zmian. Tego typu repozytioria mogą służyć jako repozytoria przechowywane na serwerze i odgrywać rolę przekaźników do udostępniania i pobierania zmian. W konsekwencji pozwala to na stworzenie strutkury jak na rysunku poniżej.

Przedstawiona infrastruktura pozwala na synchronizację zmian pomiędzy klientami, a jednocześnie serwer przechowuje jedynie historię zmian, a nie fizyczny kod źródłowy.

Jak można wyświetlić historię zmian w Gicie?

Podstawowym poleceniem do wyświetlania historii zmian jest polecenie git log. Można do tego celu posłużyć się również poleceniem git shortlog, które w przejrzystej formie wyświetli listę kontrybutorów wraz z commitami.

Jak utowrzyć nową gałąź? Jak zmienić aktywną gałąź?

Do rozwiązania zadania można podejść na kilka sposobów. Jednym sposobem jest utworzenie gałęźi i następnie zmiana aktywnej gałęzi.

• git branch nazwa_brancha — tworzy nową gałąź;
• git checkout nazwa_brancha — zmienia aktywną gałąź.

Można też wykonać to jednym poleceniem — git checkout -b nazwa_brancha.

Czym jest konflikt w Gicie? Kiedy w Gicie może wystąpić konflikt?  Jak można go rozwiązać?

Konflikt w Gicie może zaistnieć w następującej sytuacji:

1. Programista A tworzy branch feature i wprowadza na nim zmiany w istniejącym już wcześniej pliku.
2. W międzyczasie programista B na branchu master wprowadza zmiany w tym samym pliku.
3. Programista A kończy pracę na branchu feature, pushuje wprowadzone zmiany i przełącza się na mastera.
4. Programista A chce zmerge’ować mastera z branchem feature…
5. … i w tym momencie mamy konflikt. Programista B edytował ten sam plik, co programista A i system kontroli wersji nie wie, która wersja jest poprawna.

W tym momencie przed programistą A stoi zadanie na wybraniu poprawnej wersji. Brzmi to skomplikowanie, ale w praktyce jest całkiem proste. Wystarczy skasować niechciany kod a zostawić właściwy i… gotowe!

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

Polecenie git fetch jedynie pobiera dane o zmianach ze zdalnego repozytorium. Polecenie git pull oprócz pobrania zmian ze zdalnego repozytorium podejmuje próbę scalenia ich (merge) z aktywną gałęzią. Podczas scalania może wystąpić konflikt wspomniany w poprzednim pytaniu.

Do czego służy polecenie git commit --amend?

Polecenie git commit --amend pozwala na modyfikację ostatniego commita w repozytorium. Jest to szczególnie przydatne w sytuacji, gdy jakiś plik lub zmiana podczas tworzenia commita zostaną pominięte, lub w przypadku błędnego commit message.

Warto pamiętać, że nie powinno się korzystać z tego polecenia po wysłaniu commita do repozytorium zdalnego! Polecenie to modyfikuje historię Gita i jego wywołanie może w konsekwencji utrudnić pracę innym osobom pracującym z tym samym repozytorium.

Czym jest squash commitów?

Squash commitów jest scaleniem kilku commitów w jeden. Na przykład, w serwisie GitHub takie zachowanie można zdefiniować w momencie scalania pull requestów. W takim przypadku wszystkie commity ze scalanego pull requesta zostaną połączone w jeden, a następnie scalone z gałęzią docelową. W Gicie można taki rezultat uzyskać dzięki poleceniu git rebase.

Do czego służy Git LFS?

Git nie jest najlepszy miejscem do przechowywania dużych plików, czy plików binarnych tj. obrazy, filmy czy pliki audio. W tym celu powstało narzędzie o nazwie Git LFS (Large File System). Dzięki temu, w repozytorium nie są przechowywane pliki a jedynie wskaźniki (referencje) do nich. Typy plików, przechowywanych przez Git LFS można zdefiniować w pliku .gitattributes.

Opisz stany w jakich może znajdować się zmiana w Gicie.

Wyróżniamy trzy stany, w jakich może znajdować się zmiana w repozytorium. Pierwszym stanem jest stan modified. W tym stanie są domyślnie wszystkie modyfikacje poczynione od ostatniego commita. Drugim stanem jest stan staged. Aby zmiana znalazła się w tym stanie, należy skorzystać z polecenia git add i wybrać zmiany. Przy poleceniu git commit pod uwagę brane są tylko zmiany będące w stanie staged. Ostatnim stanem jest stan commited, czyli stan, w którym zmiana została zapisana w repozytorium. Przy commitowaniu możliwe jest pominięcie stanu staged poprzez skorzystanie z flagi -a przy wywołaniu polecenia git commit.

Jak można skopiować commit na inną gałąź?

Do kopiowania commitów i dodawania ich na inne gałęzie służy polecenie git cherry-pick sha_commita. Wykonanie tego polecenia spowoduje kopię commita z podaną referencją i dodaniem go do aktywnej gałęzi. Referencję do commita możemy uzyskać za pomocą polecenia git log, którego dotyczyło jedno z poprzednich pytań.

Podsumowanie

Te kilkanaście pytań to o wiele za mało, by być dobrze przygotowanym do rozmowy rekrutacyjnej. Jeszcze raz gorąco zachęcam do sprawdzenia innych wpisów na blogu oraz pobranie e-booka 106 Pytań Rekrutacyjnych Junior JavaScript Developer. Zachęcam też do zostawiania komentarzy i udostępnienia tego wpisu znajomym, którym ta wiedza może się przydać.

Źródła i materiały dodatkowe

• Pro Git – Scott Chacon and Ben Straub
• Centralized vs Distributed Version Control Systems
• GitHub Docs – Hello World
• How to Write a Git Commit Message
• What is a bare git repository?
• Git Docs – log
• Git Docs – shortlog
• What’s the difference between git fetch and git pull?
• Git Docs – Podstawy Gita – Cofanie zmian
• Rewriting history
• An open source Git extension for versioning large files
• Three States of Git and Three Sections of a Git Project
• Getting Started – What is Git?
• Git Cherry Pick

Czy wiesz, że devszczepaniak.pl jest na Facebooku?

Chcesz otrzymywać informację o nowych wpisach zaraz po publikacji?
Koniecznie zaobserwuj devszczepaniak.pl na Facebooku.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

Chcesz docenić moją pracę? Postaw mi kawę!