Hooki Git Claude Code mogą blokować wycieki sekretów, wymuszać formatowanie, uruchamiać właściwe testy i tworzyć krótkie podsumowania commitów, dzięki czemu przeglądy są szybsze.
Większość bólu podczas przeglądów nie wynika z „trudnego” kodu. Pochodzi z drobnych, uniknionych błędów, które trafiają do commita: włączona flaga debug, nie sformatowany plik generujący hałas w diffie, brak aktualizacji testu albo sekret wklejony do konfiguracji. Każdy z nich jest niewielki, ale razem zamieniają porządny przegląd w długie pingi i prośby o poprawki.
Automatyzacja w czasie commit to najprostsze miejsce, by to zatrzymać. Gdy sprawdzenia uruchamiają się tuż przed utworzeniem commita, wykrywają problemy, gdy zmiana jest jeszcze świeża w głowie autora. Naprawa błędu zajmuje kilka sekund, bo jesteś już w kontekście pracy. Porównaj to ze znalezieniem problemu dwa dni później w pull requeście, po kolejnych commitach, gdy recenzent musi pytać, co się stało.
Git hooki są praktycznym narzędziem, bo działają lokalnie, bez czekania na CI. Nie są jednak magiczne. Hooki można pominąć, źle skonfigurować lub mieć je niejednolite na różnych maszynach, jeśli zespół ich nie ustandaryzuje. Same w sobie nie gwarantują jakości. Traktuj je jako barierki, nie jako bramy.
Hooki najbardziej pomagają w zapobieganiu „review tax” — powtarzalnym, mało wartościowym uwagom, które ciągle się pojawiają. Typowe przykłady to podejrzane ciągi wyglądające jak tokeny, szum wynikający z formatowania i lintera, podstawowe sprawdzenia "czy uruchomiłeś właściwe testy?", oraz krótkie podsumowania kontekstu, które pomagają recenzentowi zrozumieć intencję.
W tym miejscu hooki Claude Code dobrze się sprawdzają: mogą wykonać nudne weryfikacje i dodać czytelny kontekst dokładnie w momencie commita.
Ustalanie oczekiwań ma znaczenie. Trzymaj lokalne hooki szybkie i przewidywalne, żeby ludzie ich nie znienawidzili. Szybkie sprawdzenia należą na laptop; cięższe do później. Dobry podział to sekundy przy commicie i minuty w CI. Jeśli hook regularnie zajmuje tyle, że ktoś sięga po „skip”, przestaje chronić repo.
Prosty przykład: zmieniasz jeden moduł i refaktoryzujesz kilka funkcji. Bez automatyzacji recenzent widzi 400 przeniesionych linii, brak wzmianki o testach i musi zadawać podstawowe pytania. Z kontrolami przy commicie commit jest sformatowany, uruchomiono odpowiedni zestaw testów, a wiadomość commita zawiera krótkie podsumowanie. Przegląd zaczyna się tam, gdzie powinien: od projektu, nie od porządków.
Hooki Git świetnie nadają się do prostych sprawdzeń, ale zwykle kończą na regułach tak/nie: „czy plik jest sformatowany?” albo „czy uruchomiłeś linter?”. Claude Code może dodać lekką warstwę osądu, czytając staged diff i kilka powiązanych plików, a następnie podejmując decyzje bliższe temu, jak ludzie oceniają zmiany.
Z hookami Claude Code hook może spojrzeć na to, co faktycznie zmieniłeś, a nie tylko na to, co jest w repo. To sprawia, że automatyzacja jest bardziej selektywna. Może skupić się na dotkniętych modułach, edytowanych plikach konfiguracyjnych i nowych zmiennych środowiskowych, zamiast traktować każdy commit jak pełny build.
Praktyczne zadania, gdzie „przeczytaj diff i pomyśl” się opłaca:
Ograniczenia mają znaczenie, bo wolny hook staje się pomijanym hookiem. Utrzymuj cel mały: dodaj barierki łapiące typowe błędy wcześnie, a nie drugi system CI przy każdym commicie.
Dobra zasada: jeśli nie może skończyć w kilka sekund, prawdopodobnie należy to przenieść do CI lub pre-push. Wiele zespołów uruchamia szybkie lokalne sprawdzenia przy commicie i zostawia cięższe zestawy testów na później.
Planuj tryby awaryjne. Jeśli wywołanie modelu przekroczy czas, zdecyduj, czy blokować commit, czy wrócić do prostszego sprawdzenia. Fallback utrzymuje przepływ przewidywalnym i zapobiega przyzwyczajeniu ludzi do wyłączania hooków.
Niektóre konfiguracje dzwonią do hostowanego modelu; inne działają w izolowanym środowisku. Zdecyduj, jaki kod może opuścić maszynę developera (jeśli w ogóle) i ogranicz, co wysyłasz. Staged diff plus mały zestaw referencyjnych plików często wystarcza.
Jeśli pracujesz z wrażliwymi repozytoriami, bądź konkretny, gdzie działa analiza i co jest logowane. Przykład: jeśli commit dodaje nową wartość konfiguracyjną jak STRIPE_SECRET=..., hook może zatrzymać commit, wyjaśnić, co wygląda ryzykownie i zasugerować przeniesienie jej do menedżera sekretów lub lokalnego pliku env, zanim trafi do zdalnego repo.
Git hooki są użyteczne tylko wtedy, gdy ludzie je włączają i nie zaczynają się bać commitów. Sztuczka polega na wyborze odpowiedniego hooka do zadania i trzymaniu wszystkiego wolnego od gorącej ścieżki.
Prosta mapa, gdzie zwykle należą sprawdzenia:
pre-commit: szybkie, lokalne sprawdzenia blokujące oczywiste problemy (formatowanie, skan sekretów, szybki lint)commit-msg: sprawdzenia dotyczące tylko wiadomości (ID ticketa, długość, konwencja)pre-push: cięższa praca warta złapania przed dotarciem do wspólnego repo (wolniejsze testy, sprawdzenia typów, build)Gdy dodajesz hooki Claude Code, traktuj je jak pomocnego recenzenta, który pojawia się natychmiast, a nie jak wąskie gardło. Wszystko, co wymaga wywołań sieciowych, pełnych testów lub długiej analizy, daj do pre-push lub CI, nie do pre-commit.
Praktyczny sposób decydowania, co uruchamiać, to sortowanie sprawdzeń według prędkości i wpływu. Jeśli łapie wysokie ryzyko (np. wyciek kluczy) i może działać w sekundę lub dwie, należy umieścić to w pre-commit. Jeśli zajmuje 30–90 sekund, przenieś do pre-push lub uruchamiaj tylko przy zmianach konkretnych plików.
Zespoły też potrzebują jasnego stanowiska dotyczącego egzekwowania. Dla repo solo opcja opt-in może być ok. W repo zespołowym powszechne jest egzekwowanie podstaw (sekrety, formatowanie, reguły wiadomości commit) i traktowanie cięższych spraw jako doradcze lokalnie, podczas gdy CI pozostaje ostatecznym strażnikiem.
Wynik hooka ma większe znaczenie, niż się wydaje. Hook, który się nie powiedzie, powinien powiedzieć, co się stało i co dalej zrobić. Trzymaj komunikaty krótkie i konkretne. Pokaż dokładny plik i linię, gdy to możliwe, podaj jedno jasne polecenie naprawcze, wyjaśnij, jak pominąć tylko w prawdziwych nagłych wypadkach (i kiedy nie robić tego), i unikaj ogromnych logów, chyba że użytkownik poprosi o „verbose”.
Przykład: jeśli eksportujesz projekt z Koder.ai i zaczynasz commitować lokalnie, szybki pre-commit może natychmiast wykryć skopiowany token API, a pre-push uruchomi wolniejsze "tylko testy dla zmienionych modułów" zanim ktoś zobaczy branch.
Sekret to cokolwiek, co pozwala komuś działać w twoim imieniu lub uzyskać dostęp do prywatnych systemów. Myśl o tokenach API, sekretach klienta OAuth, kluczach chmurowych, hasłach do baz danych, prywatnych URL-ach webhooków, kluczach podpisywania, a nawet „tymczasowych” poświadczeniach testowych. Jeden przypadkowy commit może trafić do forka, loga CI lub wklejonego diffu i wtedy już nie będzie tymczasowy.
Najłatwiejszy zysk to skanowanie tylko tego, co zamierzasz skomitować. Hook powinien sprawdzać staged changes (indeks), a nie całe repo. To utrzymuje go szybkim i eliminuje szum z powodu starych plików, których nie dotknąłeś. Robi też feedback bardziej uczciwym: „ten commit zawiera problem” zamiast „twoje repo kiedyś miało problem”.
Typowe rzeczy do wczesnego oznaczania to tokeny o wysokiej entropii (długie losowe ciągi), znane formaty kluczy (klucze AWS, tokeny GitHub, JWT), wzorce jak password=... lub api_key: ... w konfiguracjach, prywatne URL-e z wbudowanymi poświadczeniami oraz pliki .env lub skopiowane konfiguracje produkcyjne.
Fałszywe alarmy się zdarzają, szczególnie przy danych testowych, hashach lub przykładach w dokumentacji. Wprowadź allowlistę, by ludzie mogli iść dalej bez wyłączania całego sprawdzenia. Trzymaj allowlistę wąską: dokładne ścieżki plików dla fixture'ów lub wyraźne znaczniki typu „dummy” albo „example”, które detektor rozpoznaje.
Gdy znajdziesz sekret, zakończ commit z komunikatem mówiącym, co zrobić dalej. Hooki Claude Code mogą ułatwić to, tworząc krótkie wyjaśnienie na podstawie diffu, ale kluczowe są jasne, bezpieczne następne kroki:
ERROR: Possible secret detected in staged file: config/app.yaml (line 12)
Reason: looks like an API token
Next steps:
1) Remove it from the change or move it to env vars
2) Rotate the token (assume it is compromised)
3) Re-stage and retry commit
If this is a false positive, add a narrow allowlist rule in .secrets-allowlist
Konkretna sytuacja: ktoś aktualizuje backend config i dodaje TEMP_API_KEY, żeby funkcja działała w dev. Hook zatrzymuje commit, sugeruje przeniesienie do zmiennej środowiskowej i przypomina o rotacji, jeśli to był prawdziwy klucz. To małe zatrzymanie zapobiega dużemu sprzątaniu później.
Walka o formatowanie marnuje czas recenzentów, ale wolne hooki są szybkim sposobem na to, że hooki zostaną wyłączone. Słodki punkt to proste reguły, jeden narzędzie na język i dotykanie tylko tego, co ma być skomitowane.
Wybierz pojedynczy formatter na język i zrób go źródłem prawdy. Dwa formatery, które się spierają (albo formatter plus linter, który także przepisuje kod) stworzą hałas i ciągłą pogoń. Trzymaj to nudne: jeden JS/TS formatter, jeden Go formatter, jeden Dart formatter. Upewnij się, że wszyscy używają tych samych wersji, by output hooka był stabilny na różnych maszynach.
Największy zysk prędkości to formatowanie tylko staged plików. Formatowanie całego repo przy każdym commicie to główny powód narzekań na pre-commit. Podejście staged-only utrzymuje diff skupiony na tym, co zmieniłeś — a tego chcą recenzenci.
Praktyczny zestaw wyborów, który utrzymuje commity szybkie:
Auto-fix vs fail to wybór zespołu, ale mieszane podejście działa dobrze. Auto-fix jest świetny dla mechanicznych poprawek, bo unika pętli „commit, fail, uruchom ponownie, commit ponownie”. Fail może być lepsze, gdy chcesz, żeby ludzie zobaczyli problem i zdecydowali. Jeśli blokujesz, wydrukuj jedno polecenie, które każdy wykona w 10 sekund.
Standaryzuj drobne rzeczy powodujące szum między platformami. Zakończenia linii i trailing whitespace to zwykli winowajcy, zwłaszcza gdy ludzie przełączają się między Windows, macOS i CI.
Prosta polityka rzadko powodująca ból:
Gdzie hooki Claude Code mogą pomóc, to w klejeniu: wykrywanie, które staged pliki potrzebują którego formattera, uruchamianie ich w odpowiedniej kolejności i wyjaśnianie błędów w prostym języku. Na przykład, jeśli ktoś stage'uje plik Go i TS, hook może sformatować każdy odpowiednim narzędziem, ponownie je stage'ować, a potem wypisać krótką notkę typu „2 pliki sformatowane, brak zmian behawioralnych”. Recenzenci widzą czyściejsze dify, a developerzy nie czują się ukarani za częste commity.
Prosta zasada sprawia, że commity są bezpieczniejsze bez bólu: uruchamiaj tylko testy pasujące do tego, co faktycznie staged. Gdy hook patrzy na staged diff (nie na working tree), unika fałszywych alarmów spowodowanych niedokończonymi plikami.
Zacznij od wykrywania, które obszary zostały dotknięte. Większość repo ma naturalną strukturę: pakiety, serwisy, aplikacje lub moduły. Hook może przeczytać git diff --cached --name-only, a następnie zmapować te ścieżki na mały zestaw komend testowych.
Kilka reguł mapowania, które są zrozumiałe, gdy wrócisz do nich później:
web/ lub frontend/ -> uruchom npm test (lub najmniejszą docelową komendę)api/ lub server/ -> uruchom testy jednostkowe backendu (domyślnie pomiń integracje)mobile/ -> uruchom szybkie testy widgetów/jednostkowe, nie pełne suite urządzeńdb/ lub migrations/ -> uruchom lint migracji plus małą weryfikację schematushared/ -> uruchom testy pakietu shared oraz szybkie testy konsumentówJeśli używasz hooków Claude Code, możesz pójść krok dalej: poproś Claude, żeby przejrzał nazwy staged plików i zaproponował minimalny zestaw testów, a potem hook je uruchomi. Trzymaj jednak reguły decyzyjne deterministyczne, żeby zespół mógł przewidzieć, co się stanie.
Podziel pracę między commit i push. Commity powinny pozostać szybkie, żeby ludzie nie omijali hooków. Praktyczny wzorzec:
Testy flaky i wolne potrzebują jasnej polityki, inaczej hook staje się hałasem. Uzgodnij w zespole, co blokuje commit, a co tylko ostrzega. Praktyczne podejście: blokuj przy wyraźnych błędach (formatowanie, stabilne testy jednostkowe), ostrzegaj przy znanych flaky testach z krótkim komunikatem, a przenieś wolne suite do push/CI. Jeśli test jest flaky, traktuj to jak błąd: śledź go, popraw i jak najszybciej usuń tryb ostrzegawczy.
Dobry diff nie zawsze jest łatwy do przeglądnięcia. Krótkie podsumowanie przy commicie może skrócić 10-minutowe czytanie do 2-minutowej kontroli, zwłaszcza gdy zmiany dotykają wielu plików lub zawierają refaktory.
Idea jest prosta: kiedy robisz git commit, twój hook prosi Claude Code o przeczytanie staged diffu i wygenerowanie 3–6-wierszowej notatki odpowiadającej na pytania, które recenzenci zawsze mają: co się zmieniło, dlaczego to zmieniono, jak ryzykowne to jest i co sprawdzić.
Trzymaj output zwięzły i konsekwentny, by recenzenci nauczyli się mu ufać:
Możesz dodać to bezpośrednio do wiadomości commita (np. jako krótki footer), albo zapisać do pliku, który zespół wkleja do opisu pull requesta. Commit message działa dobrze, gdy chcesz, żeby kontekst podróżował z zmianą. Osobny plik lepiej, gdy zespół woli czyste, konwencjonalne tematy commitów.
Narzędzie tworzące podsumowanie powinno być bardziej rygorystyczne niż recenzent. Przed wysłaniem czegokolwiek do modelu odfiltruj linie pasujące do wzorców jak klucze API, prywatne klucze, tokeny, wartości .env i poświadczenia. Filtruj też standardowe nagłówki i ciasteczka, jeśli repo zawiera przechwycony ruch HTTP. Gdy hook wykryje wzorce wrażliwe, może zredagować linie lub użyć fallbacku do ogólnego podsumowania typu „zmiany związane z poświadczeniami zredagowane”.
Przykład: aktualizujesz endpoint billingowy i dotykasz trzech plików. Staged diff jest hałaśliwy z powodu rename'ów, ale podsumowanie mówi: „Dodano obsługę idempotency key przy tworzeniu charge, by zapobiec podwójnym obciążeniom. Powód: retry powodował duplikaty. Ryzyko: średnie (ścieżka płatności). Testy: testy jednostkowe serwisu billing, ręczne odtwarzanie żądań.” To dokładnie to, czego recenzent potrzebuje, bez czytania każdego wiersza najpierw.
Naprawiasz mały błąd i poprawiasz konfigurację w tym samym commicie. Błąd to jednowierszowa zmiana w billing/tax.go. Zmiana konfiguracji aktualizuje config/staging.yaml, wskazując nowy endpoint.
Uruchamiasz git commit -am "Fix tax rounding". Hooki Claude Code uruchamiają szybkie, przewidywalne sprawdzenia w ustalonej kolejności.
Najpierw skan sekretów patrzy na to, co zmieniłeś, a nie całe repo. Oznacza, że staging config zawiera coś, co wygląda jak prawdziwy klucz API.
ERROR: Possible secret detected in config/staging.yaml:12
Pattern: api_key=sk_live_...
Fix: remove the key and use an env var reference (e.g., API_KEY)
Override: set ALLOW_SECRETS=1 (not recommended)
Zamieniasz wartość na referencję do zmiennej środowiskowej, a potem komitujesz ponownie.
Następnie formatowanie uruchamia się tylko tam, gdzie to istotne. Jeśli twój plik Go nie jest sformatowany, hook zakończy się błędem z krótką wskazówką typu „uruchom gofmt na billing/tax.go”. Uruchamiasz formatter i hook przechodzi w sekundach.
Potem bramka testowa uruchamia ukierunkowany zestaw. Ponieważ dotknąłeś billing/, uruchamia testy jednostkowe billingowe tylko (nie cały suite). Jeśli któryś test pada, hook pokazuje dokładne polecenie do odtworzenia lokalnie. Naprawiasz edge case zaokrąglania i uruchamiasz te same testy ponownie.
Na końcu hook generuje podsumowanie dla recenzenta z diffu. Jest krótkie i konkretne, np.:
Recenzent widzi commit już czysty: bez wycieków sekretów, spójne formatowanie i testy dopasowane do zmiany. Ma też gotowe podsumowanie, więc może skupić się na logice zamiast szukać intencji.
Najszybszy sposób, by hooki zaczęły zawodzić, to sprawić, by były bolesne. Jeśli hook trwa na tyle długo, że przerywa komuś przepływ, ludzie będą go omijać przez --no-verify lub usuwać. Trzymaj wszystko ciężkie poza pre-commit i uruchamiaj to w CI lub na żądanie.
Praktyczna zasada: pre-commit powinien przypominać sprawdzenie literówki, nie suite testów. Jeśli chcesz mądrzejsze sprawdzenia od Claude Code, użyj ich do decydowania, co uruchomić, a nie do uruchamiania wszystkiego.
Uczyń hooki domyślnie szybkie, a surowe tylko gdy trzeba. Na przykład uruchamiaj szybkie formatowanie + skan sekretów przy każdym commicie, ale uruchamiaj testy tylko dla dotkniętych modułów.
Praktyczny budżet czasu:
pre-commit: 1–5 sekund łączniecommit-msg: poniżej 1 sekundypre-push lub CIAI jest świetne do sugestii, nie polityki. Jeśli poprosisz AI o „przejrzyj diff” bez reguł, dostaniesz różne wyniki za każdym razem. Zdefiniuj, co hook musi zrobić (i czego nigdy nie robić). Na przykład: może generować podsumowanie recenzenta, ale nie może przepisywać kodu, chyba że formatter już wykonał deterministyczne zmiany.
Wiele hooków przypadkowo skanuje working tree i potem przerywa commit z powodu zmian, których nie stage'owałeś. To wydaje się niesprawiedliwe.
Unikaj tego, zawsze używając staged content jako wejścia. Dobry test: edytuj plik, stage'uj tylko połowę zmian i sprawdź, czy hook raportuje tylko to, co jest staged.
Jeśli każdy commit wywołuje ostrzeżenie, ostrzeżenia stają się hałasem. Dopasuj wzorce, dodaj allowlisty dla znanych bezpiecznych ciągów i zdegraduj „może” do ostrzeżenia z jasną naprawą.
Konkretny przykład: jeśli skaner sekretów flaguje testowe klucze w fixtures/, dodaj regułę ignorowania tego folderu, ale nadal blokuj prawdziwe klucze w plikach konfiguracyjnych aplikacji.
Jeśli chcesz, by hooki Claude Code pomagały bez irytowania zespołu, cel jest prosty: złap prawdziwe problemy wcześnie, bądź cichy, gdy wszystko jest w porządku i trzymaj pętlę commita szybką.
Praktyczna lista kontrolna działająca w większości repo:
Mały detal, który się opłaca: spraw, by podsumowanie dla recenzenta wyglądało tak samo za każdym razem. Prosty szablon wystarczy i wytrenowuje recenzentów do szybkiego skanowania.
Review summary:
- What changed: <1-2 bullets>
- Risky areas: <files/modules>
- Tests run: <command or “not run + why”>
Kolejne kroki ułatwiające adopcję:
Jeśli lubisz budować narzędzia w podejściu chat-first, Koder.ai (koder.ai) może być pomocny przy generowaniu małych skryptów pomocniczych wokół twoich hooków i iterowaniu bezpiecznie ze snapshotami i rollbackiem, zanim wyeksportujesz kod źródłowy do repo.
Zacznij od powtarzających się problemów, które marnują czas recenzentów:
Wszystko co wolne (pełny zestaw testów, głęboka analiza statyczna) zostaw na pre-push lub CI.
Dobrym domyślem jest:
pre-commit dla szybkich sprawdzeń patrzących na staged changes (sekrety, formatowanie, szybki lint, selektywne testy jednostkowe)commit-msg dla reguł wiadomości commit (długość, format, ID ticketa)pre-push dla wolniejszych, ale wciąż lokalnych sprawdzeń (szersze testy, build)Jeśli sprawdzenie regularnie zajmuje więcej niż kilka sekund, przenieś je później.
Traktuj hooki w czasie commit jako barierki, a nie jedyne egzekwowanie zasad.
Praktyczna polityka: hooki pomagają developerom; CI chroni główną gałąź.
Skanuj staged diff (indeks), nie całe repo.
Jeśli potrzebujesz skanu całego repo, uruchamiaj go cyklicznie lub w CI.
Blokuj przy wysokiej pewności (prawdziwe formaty kluczy, bloki prywatnych kluczy, oczywiste password= w konfiguracji). Ostrzegaj, gdy jest niejednoznacznie.
Dodaj wąską allowlistę dla bezpiecznych przypadków, np.:
DUMMY_KEY)Jeśli ludzie widzą ciągłe fałszywe alarmy, wyłączą hooka.
Formatuj tylko staged pliki i używaj jednego formatera na język.
Praktyczne domyśły:
To utrzymuje czyste dify bez zamieniania każdego commita w długą przeprawę.
Mapuj zmienione ścieżki na mały zestaw szybkich komend testowych.
Przykładowe podejście:
git diff --cached --name-onlypre-push lub CITo utrzymuje commity szybkie, a mimo to łapie najczęstsze regresje wcześnie.
Zachowaj to krótkie i spójne (3–6 linii). Prosty szablon:
Możesz dołączyć to do wiadomości commita lub zapisać jako tekst do opisu PR. Commit message sprawdza się, gdy chcesz, żeby kontekst podróżował z commitem.
Redaguj przed wysłaniem czegokolwiek do modelu i bądź konserwatywny.
.env, prywatne klucze, ciasteczka lub nagłówki authDomyślnie dziel mniej, szczególnie w prywatnych repo.
Spraw, by hooki były przewidywalne i szybkie:
pre-commit)Jeśli hook będzie niestabilny lub wolny, deweloperzy sięgną po --no-verify.