20 Najtrudniejszych pytań rekrutacyjnych z Git

Git to niezbędne narzędzie każdego programisty i standard w branży. W tym artykule znajdziesz przegląd kluczowych pytań rekrutacyjnych dotyczących Gita wraz z praktycznymi wyjaśnieniami. To idealna pomoc w przygotowaniach do rozmowy rektutacyjnej lub uporządkowania wiedzy o tym popularnym systemie kontroli wersji.

Czym jest Git?

Git to Rozproszony System Kontroli Wersji (DVCS). Może śledzić zmiany w pliku i pozwala na powrót do dowolnej konkretnej zmiany. Jego rozproszona architektura zapewnia wiele korzyści w porównaniu z innymi systemami kontroli wersji (VCS), takimi jak SVN. Jedną z głównych zalet jest to, że nie polega on na centralnym serwerze do przechowywania wszystkich wersji plików projektu.

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

Różnica pomiędzy Gitem a SVN sprowadza się do ich architektury. Git jest rozproszonym systemem kontroli wersji (DVCS), co oznacza, że każdy programista posiada pełną kopię repozytorium wraz z całą historią zmian. SVN (Subversion) natomiast jest systemem scentralizowanym, gdzie wszystkie dane przechowywane są na jednym, centralnym serwerze. W praktyce oznacza to, że w przypadku Gita większość operacji można wykonywać lokalnie, bez konieczności połączenia z serwerem, co przekłada się na szybkość działania. W SVN natomiast praktycznie każda operacja wymaga połączenia z centralnym serwerem. Dodatkowo, rozproszona natura Gita zwiększa bezpieczeństwo danych – awaria centralnego serwera nie oznacza utraty całej historii projektu, jak to ma miejsce w SVN.

Jak działa scentralizowany przepływ pracy?

Scentralizowany przepływ pracy wykorzystuje centralne repozytorium jako pojedynczy punkt wejścia dla wszystkich zmian w projekcie. Domyślna gałąź programistyczna nazywa się master i wszystkie zmiany są zatwierdzane w tej gałęzi. Programiści zaczynają od sklonowania centralnego repozytorium. W swoich lokalnych kopiach projektu edytują pliki i zatwierdzają (commitują) zmiany. Te nowe zatwierdzenia (commity) są przechowywane lokalnie. Aby opublikować zmiany w oficjalnym projekcie, programiści wypychają swoją lokalną gałąź master do centralnego repozytorium. Zanim programista będzie mógł opublikować swoją funkcjonalność, musi pobrać zaktualizowane zatwierdzenia centralne i wykonać rebase swoich zmian na ich podstawie. W porównaniu z innymi przepływami pracy, scentralizowany przepływ pracy nie ma zdefiniowanych wzorców pull requestów ani forkowania.

Czym jest fork w Gicie? Jaka jest różnica między forkiem, gałęzią a klonem?

Fork

Fork w Gicie to zdalna, serwerowa kopia repozytorium, która jest odrębna od repozytorium oryginalnego. Fork wykorzystuje się najczęściej w kontekście projektów open-source, aby wprowadzać zmiany w kodzie bez potrzeby modyfikacji bezpośrednio w oryginalnym repozytorium. Użytkownik ma pełną kontrolę nad swoim forkiem i może później zaproponować zmiany w projekcie źródłowym poprzez pull request. Fork dotyczy bardziej platform takich jak GitHub, GitLab czy Bitbucket, a nie samego narzędzia Git.

Przykład: Jeśli użytkownik chce dodać nową funkcjonalność do otwartoźródłowego projektu, forkuje repozytorium, wprowadza zmiany u siebie, a następnie wysyła pull request do repozytorium głównego.

Klon

Klonowanie (ang. clone) to proces tworzenia lokalnej kopii zdalnego repozytorium na komputerze użytkownika. Klon obejmuje całe repozytorium, w tym wszystkie historię zmian, branche oraz tagi. Jest to operacja natywna dla Gita i pozwala pracować lokalnie na pełnej kopii repozytorium.

Różnice między forkiem a klonem:

  • Fork pozostaje na poziomie serwera (np. GitHub, GitLab), jako niezależne repozytorium.
  • Klon jest lokalną kopią, pozwala na pracę na komputerze użytkownika, ale wciąż odnosi się do oryginalnego repozytorium i/lub forka (zależnie od źródła klonowania).

Branch

Branch w Gicie to mechanizm rozwidlenia ścieżki rozwoju w jednym repozytorium. Każdy branch (np. main, develop, feature/xyz) to niezależna wersja projektu, pozwalająca na przeprowadzanie nowych funkcji, poprawek błędów lub eksperymentów. Branch jest częścią tego samego repozytorium, a wprowadzone zmiany mogą zostać scalone (ang. merge) z innymi branchami w przyszłości.

Różnice między branch, forkiem i klonem:

  • Branch to ścieżka rozwoju wewnątrz tego samego repozytorium, która umożliwia eksperymentowanie bez wpływu na główną wersję kodu.
  • Fork to niezależne repozytorium, które jest odtworzeniem innego projektu (często na serwerze).
  • Klon jest lokalną kopią istniejącego repozytorium z całą jego historią i branchami, dającą pełną swobodę pracy w środowisku lokalnym.

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

Różnica między git pull a git fetch to sposób, w jaki zarządzają synchronizacją lokalnego repozytorium zdalnym:

  1. git fetch:
  • Pobiera zmiany z repozytorium zdalnego do repozytorium lokalnego
  • Nie wykonuje automatycznej integracji zmian z aktualnym branchem roboczym
  • Aktualizuje tylko remote-tracking branches (np. origin/main)
  • Jest bezpieczniejsza operacja, bo nie modyfikuje working directory
  1. git pull:
  • Jest kombinacją dwóch komend: git fetch + git merge
  • Pobiera zmiany ze zdalnego repozytorium i automatycznie integruje je z aktualnym branchem
  • Modyfikuje working directory
  • Może potencjalnie powodować konflikty, które trzeba rozwiązać

Przykład użycia

# Bezpieczniejsze podejście (dwu-krokowe)
git fetch origin
git merge origin/main

# Równoważne jednemu
git pull origin main

Przydatne materiały:

Musisz zaktualizować swoje lokalne repozytoria. Jakich poleceń Gita użyjesz?

Aby zaktualizować swoje lokalne repozytoria, zalecane polecenia to:

  1. git fetch – pobiera najnowsze zmiany ze zdalnego repozytorium i aktualizuje lokalne trackujące branch. Dzięki temu masz pełen wgląd w zmiany, które zostały wprowadzone przez innych, bez modyfikacji lokalnego stanu pracy.
   git fetch origin
  1. git pull – jest skróconą formą dwóch poleceń: najpierw wykonuje git fetch, a następnie git merge. To polecenie pobiera zmiany ze zdalnego repozytorium i automatycznie scala je z lokalnym stanem bieżącej branch.
   git pull origin <nazwa_branch>

W zależności od Twojego workflow możesz użyć jednego z powyższych podejść. Jeśli chcesz zachować większą kontrolę nad integracją pobranych zmian (np. rozwiązywać konflikty manualnie lub stosować rebase), najpierw pobierz zmiany poleceniem git fetch, a następnie wybierz sposób scalenia (np. git merge lub git rebase). Przydatne materiały:

Czy mógłbyś wyjaśnić, na czym polega Gitflow?

Gitflow to zaawansowany model workflow, w którym repozytorium Git jest uporządkowane poprzez wyraźny podział branch na potrzeby różnych etapów rozwoju oprogramowania. Model ten pozwala na równoległe rozwijanie nowych funkcjonalności, przygotowywanie wydań oraz szybkie wdrażanie krytycznych poprawek. Poniżej przedstawiam kluczowe elementy Gitflow:

  • Branch główny (master) – zawiera stabilną wersję kodu, która może być wdrożona na środowisku produkcyjnym.
  • Branch developerski (develop) – jest miejscem integrowania wszystkich nowych funkcjonalności. Każda zmiana trafia tutaj przed przygotowaniem wydania.
  • Branch funkcjonalny (feature) – dla każdej nowej funkcjonalności tworzony jest dedykowany branch, który jest rozwijany niezależnie od pozostałych. Po zakończeniu prac i weryfikacji zmiany są scalane z branchem develop.
  • Branch wydania (release) – przeznaczony do finalnych poprawek, przygotowania dokumentacji czy testów przed wdrożeniem na środowisko produkcyjne.
  • Branch hotfix – używany do szybkiego wprowadzania krytycznych poprawek na już wdrożonej wersji. Po naprawie zmiany są scalane zarówno z branchem master, jak i develop, aby zachować spójność kodu.

Stosowanie Gitflow gwarantuje, że rozwój, testy oraz wdrożenia odbywają się w uporządkowany sposób, co przekłada się na większą stabilność projektu oraz łatwość w zarządzaniu wieloma równolegle prowadzonymi zadaniami.

Przydatne materiały:

Czym jest git cherry-pick?

Polecenie git cherry-pick jest zazwyczaj używane do wprowadzania określonych zatwierdzeń z jednej gałęzi w repozytorium do innej gałęzi. Typowym zastosowaniem jest przenoszenie zatwierdzeń z gałęzi konserwacyjnej do gałęzi programistycznej. Jest to w przeciwieństwie do innych sposobów, takich jak scalanie i rebase, które zwykle stosują wiele zatwierdzeń do innej gałęzi. Rozważ:

// Wybieranie zatwierdzenia o podanym hash'u
git
cherry - pick < commit - hash >

Czym jest "bare git" repozytorium?

  • Jest to repozytorium utworzone bez katalogu roboczego.

  • Aby zainicjować bare repozytorium:

    // Inicjalizacja bare repozytorium Gita
git init --bare .

  • Jest zazwyczaj używane jako zdalne repozytorium, które jest współdzielone między kilkoma różnymi osobami.

  • Zawiera tylko dane repozytorium (odniesienia, zatwierdzenia) i nic więcej.

Kiedy powinieneś używać git stash?

Polecenie git stash pobiera niezatrzymane zmiany (zarówno te w kolejce, jak i te, które nie zostały dodane do kolejki), zapisuje je do późniejszego wykorzystania, a następnie przywraca je z kopii roboczej. Rozważ:

$ git status
On branch master
Changes to be committed:
new file: style.css
Changes not staged for commit:
modified: index.html

$ git stash
Saved working directory and index state WIP on master: 5002d47 our new homepage
HEAD is now at 5002d47 our new homepage

$ git status
On branch master
nothing to commit, working tree clean

Jednym z miejsc, w których moglibyśmy użyć stashingu, jest sytuacja, gdy odkryjemy, że zapomnieliśmy czegoś w naszym ostatnim zatwierdzeniu i już zaczęliśmy pracować nad następnym w tej samej gałęzi:

# Załóżmy, że ostatnie zatwierdzenie zostało już wykonane
# zaczynamy pracę nad kolejną poprawką i odkrywamy, że czegoś brakuje
# chowamy bieżący bałagan, który zrobiliśmy
$ git stash save

# kilka zmian w katalogu roboczym
# a teraz dodajemy je do ostatniego zatwierdzenia:
$ git add -u
$ git commit --ammend

# powrót do pracy!
$ git stash pop

Musisz cofnąć się do poprzedniego commitu i nie dbasz o ostatnie zmiany. Jakich poleceń powinieneś użyć?

Aby cofnąć się do poprzedniego commitu, całkowicie porzucając ostatnie zmiany, należy użyć polecenia:

git reset --hard HEAD^

Powyższa komenda powoduje, że HEAD oraz wskaźnik bieżącej branch (branch) zostają przesunięte do commit-u poprzedzającego aktualny. Dzięki opcji --hard, zarówno obszar staging, jak i katalog roboczy zostaną zaktualizowane, co skutkuje trwałym usunięciem ostatnich zmian.

Dodatkowo, warto zapoznać się z dokumentacją Git dotyczącą resetowania commitów:

Czy możesz wyjaśnić, co robi git reset w prostych słowach?

Ogólnie rzecz biorąc, funkcja git reset polega na pobraniu bieżącej gałęzi i zresetowaniu jej tak, aby wskazywała gdzie indziej, i ewentualnie przeniesieniu indeksu i katalogu roboczego.

- A - B - C (HEAD, master)
# po git reset B (--mixed domyślnie)
- A - B (HEAD, master)      # - C nadal istnieje (katalog roboczy nie zmienił stanu), ale żadna gałąź już do niego nie wskazuje

Pamiętaj, że w git masz:

  • wskaźnik HEAD, który mówi Ci, nad jakim commitem pracujesz
  • katalog roboczy, który reprezentuje stan plików w twoim systemie
  • obszar przejściowy (zwany również indeksem), który "przygotowuje" zmiany, aby można je było później commitować razem

Zatem rozważ:

  • git reset --soft przenosi HEAD, ale nie dotyka obszaru przejściowego ani katalogu roboczego.
  • git reset --mixed przenosi HEAD i aktualizuje obszar przejściowy, ale nie katalog roboczy.
  • git reset --merge przenosi HEAD, resetuje obszar przejściowy i próbuje przenieść wszystkie zmiany w katalogu roboczym do nowego katalogu roboczego.
  • git reset --hard przenosi HEAD i dostosowuje obszar przejściowy i katalog roboczy do nowego HEAD, odrzucając wszystko.

Przypadki użycia:

  • Użyj --soft, gdy chcesz przenieść się do innego commitu i naprawić rzeczy bez "utraty miejsca". To dość rzadkie, że tego potrzebujesz.
  • Użyj --mixed (co jest domyślne), gdy chcesz zobaczyć, jak wyglądają rzeczy w innym commicie, ale nie chcesz stracić żadnych zmian, które już masz.
  • Użyj --merge, gdy chcesz przenieść się do nowego miejsca, ale włączyć zmiany, które już masz, do katalogu roboczego.
  • Użyj --hard, aby wyczyścić wszystko i zacząć od nowa w nowym commicie.

Jak utworzyć bare repozytorium z istniejącego?

Uruchom poniższe polecenie:

// Klonowanie repozytorium jako bare repozytorium
git clone --mirror <repo_source_path>

Flaga --mirror mapuje wszystkie odniesienia (w tym zdalne gałęzie śledzące, notatki itp.) i ustawia konfigurację refspec w taki sposób, że wszystkie te odniesienia są nadpisywane przez git remote update w repozytorium docelowym.

Jaka jest różnica między git stash pop a git stash apply?

git stash pop odrzuca (domyślnie najwyższy) stash po jego zastosowaniu, podczas gdy git stash apply pozostawia go na liście stashy do ewentualnego późniejszego ponownego użycia (lub możesz go potem usunąć za pomocą git stash drop). Dzieje się tak, chyba że po git stash pop wystąpią konflikty (powiedzmy, że twoje schowane zmiany kolidują z innymi zmianami, które wprowadziłeś od czasu utworzenia stashy), w takim przypadku nie usunie stashy, zachowując się dokładnie tak samo jak git stash apply. Inny sposób patrzenia na to: git stash pop to git stash apply && git stash drop.

Czym jest HEAD w Gicie?

W Git HEAD to wskaźnik, który odwołuje się do aktualnie aktywnego commit-u lub, bardziej precyzyjnie, do commit-u na szczycie bieżącego branch. Można o nim myśleć jako o "katalogu nawigacyjnym" repozytorium, który wskazuje, gdzie znajdują się bieżące zmiany. Kilka kluczowych punktów:

  • Aktualny commit: HEAD reprezentuje ostatni commit w historii branch, nad którym pracujesz. Dzięki temu Git wie, od którego commit-u rozpocząć operacje, takie jak commitowanie nowych zmian.
  • Detachment: Jeśli HEAD zostanie ustawiony bezpośrednio na konkretny commit (a nie na nazwę branch), mówimy o tzw. "detached HEAD". W takim przypadku praca nad zmianami nie odnosi się do konkretnego branch, co może być użyteczne przy eksploracji historii lub testowaniu.
  • Nawigacja po historii: HEAD pomaga Gitowi śledzić aktualny stan repozytorium, umożliwiając operacje takie jak checkout, rebase, czy merge, bazujące na bieżącym kontekście pracy.

Dla pogłębienia wiedzy polecamy zapoznanie się z następującymi materiałami:

  • Pro Git Book – darmowa, dogłębna lektura, omawiająca wszystkie aspekty Gita.
  • Atlassian Git Tutorials – praktyczne tutoriale, w których możesz zobaczyć, jak HEAD funkcjonuje w codziennej pracy.
  • Artykuły techniczne i blogi często poruszają kwestie związane z detached HEAD oraz zaawansowanymi operacjami na branch, co stanowi doskonałe uzupełnienie wiedzy.

Jaka jest różnica między git clone, git clone --bare a git clone --mirror?

  • git clone origin-url jest głównie używany do wskazania istniejącego repozytorium i utworzenia klonu lub kopii tego repozytorium w nowym katalogu. Ma swoją własną historię, zarządza swoimi własnymi plikami i jest całkowicie izolowanym środowiskiem od oryginalnego repozytorium.
  • git clone --bare origin-url tworzy kopię zdalnego repozytorium z pominiętym katalogiem roboczym. Również gałęzie heads w zdalnym repozytorium są kopiowane bezpośrednio do odpowiadających im lokalnych gałęzi heads bez mapowania. Nie są tworzone ani gałęzie śledzące zdalne repozytoria, ani powiązane zmienne konfiguracyjne.
  • git clone --mirror origin-url sklonuje wszystkie rozszerzone odniesienia zdalnego repozytorium i utrzyma konfigurację śledzenia gałęzi zdalnych. Wszystkie lokalne odniesienia (w tym zdalne gałęzie śledzące, notatki itp.) będą nadpisywane za każdym razem, gdy pobierzesz dane, więc zawsze będzie takie samo jak oryginalne repozytorium.

Kiedy użyłbyś git clone --bare zamiast git clone --mirror?

Załóżmy, że origin ma kilka gałęzi (master (HEAD), next, pu i maint), kilka tagów (v1, v2, v3), kilka gałęzi zdalnych (devA/master, devB/master) i kilka innych odniesień (refs/foo/bar, refs/foo/baz, które mogą być notatkami, stashami, przestrzeniami nazw innych programistów, kto wie).

  • git clone --bare: Otrzymasz wszystkie skopiowane tagi, gałęzie lokalne master (HEAD), next, pu i maint, żadnych gałęzi śledzących zdalne repozytoria. Oznacza to, że wszystkie gałęzie są kopiowane tak, jak są, i jest skonfigurowane całkowicie niezależnie, bez oczekiwania na ponowne pobranie. Wszelkie gałęzie zdalne (w sklonowanym zdalnym repozytorium) i inne odniesienia są całkowicie ignorowane.

  • git clone --mirror: Każde z tych odniesień zostanie skopiowane tak, jak jest. Otrzymasz wszystkie tagi, gałęzie lokalne master (HEAD), next, pu i maint, gałęzie zdalne devA/master i devB/master, inne odniesienia refs/foo/bar i refs/foo/baz. Wszystko jest dokładnie tak, jak było w sklonowanym zdalnym repozytorium. Śledzenie zdalne jest skonfigurowane tak, że jeśli uruchomisz git remote update, wszystkie odniesienia zostaną nadpisane z origin, tak jakbyś właśnie usunął mirror i sklonował go ponownie. Jak pierwotnie mówiła dokumentacja, jest to mirror. Ma być funkcjonalnie identyczną kopią, wymienną z oryginałem.

Podsumowując,

  • git clone --bare służy do utworzenia kopii zdalnego repozytorium z pominiętym katalogiem roboczym.
  • git clone --mirror służy do sklonowania wszystkich rozszerzonych odniesień zdalnego repozytorium i utrzymania konfiguracji śledzenia gałęzi zdalnych.

Jak możesz użyć git bisect do określenia źródła błędu (regresji)?

git bisect to narzędzie diagnostyczne umożliwiające zlokalizowanie commit-u, w którym wprowadzono błąd lub regresję, poprzez zastosowanie algorytmu wyszukiwania binarnego. W praktyce polega to na systematycznym przesuwaniu się po historii commit-ów projektu, oceniając, czy testowany commit jest poprawny (good) czy wadliwy (bad).

Jak działa git bisect?

  1. Inicjalizacja sesji bisekcji:
    Najpierw uruchamiamy proces bisekcji za pomocą git bisect start. Następnie oznaczamy znany commit z błędem jako bad oraz wskazujemy ostatni commit, który działał poprawnie, jako good.
git bisect start
   git bisect bad
   git bisect good <commit_id>

  1. Automatyczne dzielenie historii:
    Git automatycznie wybierze commit pośrodku przedziału między znanym dobrym a złym commit-em. Następnie należy przetestować ten commit, aby ustalić, czy zawiera błąd.

  2. Oznaczenie wyników testu:
    W zależności od wyniku testu określamy:

  • Jeśli commit zawiera błąd: git bisect bad
  • Jeśli commit jest poprawny: git bisect good

Na tej podstawie narzędzie zawęża przedział poszukiwań, aż zostanie zidentyfikowany commit, w którym wprowadzona została regresja.

  1. Zakończenie sesji:
    Po zlokalizowaniu problematycznego commit-u, proces można zakończyć poleceniem:
git bisect reset

Dlaczego warto korzystać z git bisect?

  • Szybka diagnostyka regresji: Proces binarnego wyszukiwania umożliwia znalezienie problematycznego commit-u w logarytmicznym czasie, co znacząco przyspiesza diagnozowanie błędów w dużych projektach.
  • Automatyzacja testów: git bisect można zintegrować z automatycznymi testami, co pozwala na automatyczne oznaczanie commit-ów jako good lub bad w oparciu o wyniki testów.

Przydatne materiały

  • Oficjalna dokumentacja git bisect – zawiera szczegółowy opis poleceń i przykłady użycia.
  • Pro Git (Scott Chacon, Ben Straub) – szczegółowa lektura omawiająca m.in. korzystanie z narzędzi diagnostycznych Git. Książkę można przeczytać online: Pro Git Book.
  • Artykuły na blogach technicznych, takich jak Atlassian Git Tutorials czy GitHub Guides, oferują praktyczne przykłady i najlepsze praktyki.

Jak poprawić starsze commity Gita?

Aby poprawić starsze commity w repozytorium Git, możesz skorzystać z interaktywnego rebase. Dzięki temu narzędziu możesz edytować, łączyć (squash), rozdzielać lub modyfikować komunikaty commitów sprzed pewnego czasu. Poniżej przedstawiam ogólny schemat postępowania:

  1. Wybierz zakres commitów do edycji:
    Użyj polecenia, w którym określisz liczbę commitów, które chcesz zmodyfikować. Przykładowo, jeśli chcesz podejrzeć ostatnie 5 commitów, wykonaj:
git rebase -i HEAD~5
  1. Interaktywny edytor rebase:
    Po wykonaniu powyższego polecenia otworzy się edytor, w którym zobaczysz listę commitów. Każdy commit jest poprzedzony poleceniem (domyślnie pick).
  • Aby zmodyfikować dany commit (np. jego komunikat), zmień pick na reword.
  • Możesz także użyć edit, jeśli chcesz wprowadzić zmiany w zawartości commitów.
  1. Wprowadzanie poprawek:
    Po zapisaniu zmian edytor zamknie się, a Git przechodzi do edycji określonych commitów. Dla commitów oznaczonych jako reword, Git poprosi o nowy komunikat. Jeśli wybrałeś edit, masz możliwość modyfikacji zawartości, a następnie kontynuowania rebase za pomocą:
git commit --amend
   git rebase --continue
  1. Bezpieczne publikowanie zmian:
    Pamiętaj, że modyfikacja starszych commitów zmienia historię repozytorium. Jeśli te commit'y zostały już opublikowane, konieczne może być wymuszone przesłanie zmian (np. git push --force-with-lease) oraz poinformowanie zespołu o wprowadzonych zmianach, aby uniknąć konfliktów.

Przydatne materiały

  • Oficjalna dokumentacja Git
    Git Rebase Documentation

  • Książka "Pro Git" (rozdział o rebase)
    Pro Git Book

  • Artykuły i tutoriale:

    • Atlassian przygotował bardzo przystępny tutorial na temat zmiany historii commitów:
      Atlassian - Rewriting History
    • Blogi i artykuły poświęcone najlepszym praktykom związanym z rebase, np. wyszukaj "git interactive rebase best practices" dla bardziej zaawansowanych scenariuszy.

Czym są "Git hooks"?

Git hooks to mechanizm umożliwiający automatyczne wywoływanie skryptów przed lub po wykonaniu określonych operacji w systemie Git. Są to skrypty wykonywane zarówno po stronie klienta, jak i serwera, które pomagają w egzekwowaniu zasad, walidacji kodu czy automatyzacji zadań, na przykład:

  • Pre-commit: Skrypt wywoływany przed zatwierdzeniem zmian (commit), który może służyć do analizy jakości kodu, uruchamiania testów jednostkowych lub sprawdzania formatowania.
  • Commit-msg: Skrypt uruchamiany po wprowadzeniu komunikatu zatwierdzenia, umożliwiający walidację zgodności treści komunikatu z przyjętymi standardami.
  • Post-commit: Skrypt, który wykonywany jest zaraz po zatwierdzeniu zmian, często wykorzystywany do wysyłania powiadomień lub aktualizacji dokumentacji.
  • Pre-push: Skrypt uruchamiany przed wypchnięciem zmian do zdalnego repozytorium, mogący zatrzymać proces push, jeśli wykryje nieprawidłowości.

Mechanizm ten pozwala na automatyzację wielu zadań, zwiększenie jakości kontroli kodu źródłowego oraz usprawnienie procesów developerskich. Dzięki Git hooks można wdrożyć niestandardowe reguły i zabezpieczenia bezpośrednio w lokalnym repozytorium, co daje duże możliwości dostosowania workflow do specyficznych potrzeb zespołu czy projektu.

Dodatkowe materiały i źródła, które mogą być pomocne:

Powrót do blogu

Zostaw komentarz

Pamiętaj, że komentarze muszą zostać zatwierdzone przed ich opublikowaniem.