Claude Code git-hooks voor veiligere commits en snellere reviews

Waarom commit-time automatisering ertoe doet\n\nDe meeste review-pijn komt niet door “moeilijke” code. Het komt door vermijdbare foutjes die in een commit sluipen: een ingeschakelde debug-flag, een ongeformatteerd bestand dat lawaaierige diffs maakt, een vergeten testupdate, of een geheime sleutel in een config. Elk afzonderlijk is klein, maar samen veranderen ze een schone review in een trage heen-en-weer discussie.\n\nCommit-time automatisering is de makkelijkste plek om dat tegen te houden. Als checks vlak voordat een commit wordt gemaakt draaien, vangen ze problemen terwijl de wijziging nog vers in je hoofd is. Een fout herstellen duurt seconden omdat je al in de context van het werk zit. Vergelijk dat met het vinden ervan twee dagen later in een pull request, nadat er meer commits bijgekomen zijn en de reviewer moet vragen wat er gebeurde.\n\nGit hooks zijn een praktisch hulpmiddel omdat ze lokaal draaien, zonder te wachten op CI. Maar ze zijn geen magie. Hooks kunnen worden overgeslagen, verkeerd geconfigureerd of inconsistent zijn tussen machines als je team ze niet standaardiseert. Ze kunnen ook niet op zichzelf kwaliteit garanderen. Zie ze als geleiderails, niet als poorten.\n\nWaar hooks het meest helpen is het voorkomen van “review tax”, de repetitieve, lage-waarde feedback die steeds terugkomt. Veelvoorkomende voorbeelden zijn gevoelige strings die op tokens lijken, formatting- en lint-ruis, basiscontroles zoals “heb je de juiste tests gedraaid?”, en korte contextsamenvattingen die een reviewer helpen de intentie te begrijpen.\n\nHier passen Claude Code git hooks goed: ze kunnen het saaie verificatiewerk doen en precies op het moment van commit een beetje menselijk leesbare context toevoegen.\n\nHet stellen van verwachtingen is belangrijk. Houd lokale hooks snel en voorspelbaar zodat mensen ze niet haten. Snelle checks horen op je laptop; langzame checks horen later. Een goede verdeling is seconden bij commit-tijd en minuten in CI. Als een hook zo vaak traag is dat iemand naar “skip” grijpt, stopt hij je repo te beschermen.\n\nEen eenvoudig voorbeeld: je past één module aan en refactort een paar functies. Zonder automatisering ziet een reviewer 400 verplaatste regels, geen tests genoemd, en moet basisvragen stellen. Met commit-time checks is de commit geformatteerd, is een relevante testset uitgevoerd en bevat het commitbericht een korte samenvatting. De review begint waar hij zou moeten beginnen: bij het ontwerp, niet bij de schoonmaak.\n\n## Wat Claude Code toevoegt aan git hooks\n\nGit hooks zijn geweldig voor simpele checks, maar ze stoppen meestal bij ja-of-nee regels: “is het bestand geformatteerd?” of “heb je de linter gedraaid?”. Claude Code kan een lichtgewicht laag van oordeel toevoegen door je staged diff en een paar gerelateerde bestanden te lezen en dan beslissingen te nemen die beter overeenkomen met hoe mensen wijzigingen reviewen.\n\nMet Claude Code git hooks kan de hook kijken naar wat je daadwerkelijk hebt veranderd, niet alleen wat in de repo bestaat. Dat maakt automatisering selectiever. Het kan zich focussen op aangeraakte modules, bewerkte configbestanden en nieuwe omgevingsvariabelen, in plaats van elke commit als een volledige build te behandelen.\n\nPraktische taken waar “lees de diff en denk” zich uitbetaalt:\n\n- Markeer waarschijnlijke secrets (API-keys, tokens, private keys), zelfs als ze licht geobfusceerd of over meerdere regels verdeeld zijn.\n- Leg formatting af met context, zoals alleen formatters op staged bestanden draaien en waarschuwen wanneer een formatter enorme ongerelateerde churn zou veroorzaken.\n- Stel tests voor of eis ze op basis van wat er veranderd is (bijvoorbeeld: “je raakte betalingslogica aan, draai deze unit tests”) in plaats van “draai alles”.\n- Genereer een korte reviewer-samenvatting uit de diff: wat is veranderd, waarom, risicogebieden en wat te verifiëren.\n\nBeperkingen doen ertoe omdat een langzame hook een overgeslagen hook wordt. Houd het doel klein: voeg geleiderails toe die veelvoorkomende fouten vroeg vangen, geen tweede CI-systeem bij elke commit.\n\n### Snelheid en betrouwbaarheid eerst\n\nEen goede regel is: als het niet binnen een paar seconden klaar kan zijn, hoort het waarschijnlijk in CI of een pre-push hook. Veel teams draaien snelle lokale checks bij commit-tijd en laten zwaardere testsuites voor later.\n\nPlan voor faalmodi. Als een modelaanroep time-out gaat, beslis dan of je de commit blokkeert of terugvalt op een eenvoudigere check. Een fallback houdt de workflow voorspelbaar en voorkomt dat mensen leren hooks uit te schakelen.\n\n### Privacy en offline versus online\n\nSommige setups roepen een gehost model aan; andere draaien in een meer geïsoleerde omgeving. Bepaal welke code een ontwikkelaarsmachine mag verlaten (indien van toepassing) en beperk wat je stuurt. De staged diff plus een klein aantal referentiebestanden is vaak genoeg.\n\nAls je met gevoelige repositories werkt, wees expliciet over waar de analyse draait en wat gelogd wordt. Een concreet voorbeeld: als een commit een nieuwe configwaarde toevoegt zoals STRIPE_SECRET=..., kan de hook de commit stoppen, uitleggen wat risicovol lijkt en suggereren deze naar een secret manager of lokaal env-bestand te verplaatsen voordat het de remote repo bereikt.\n\n## Kies de juiste hooks en houd ze snel\n\nGit hooks zijn alleen nuttig als mensen ze aangeschakeld houden en niet leren commits te vrezen. De truc is de juiste hook voor de juiste taak kiezen en alles trage uit het kritieke pad houden.\n\nEen eenvoudige kaart waar checks meestal horen:\n\n- pre-commit: snelle, lokale checks die duidelijke problemen blokkeren (formatting, secrets-scan, snelle lint)\n- commit-msg: checks die alleen het bericht nodig hebben (ticket-ID, lengte, conventioneel formaat)\n- pre-push: zwaarder werk dat nog steeds de moeite waard is vóór het gedeelde repo (langzamere tests, type checks, build)\n\nWanneer je Claude Code git hooks toevoegt, behandel ze als een behulpzame reviewer die direct opduikt, niet als een knelpunt. Zet alles wat netwerkcalls, volledige test-suites of lange analyses vereist in pre-push of CI, niet in pre-commit.\n\nEen praktische manier om te beslissen wat waar draait is checks sorteren op snelheid en impact. Als het hoge-risico issues vangt (zoals gelekte sleutels) en in een seconde of twee kan draaien, hoort het in pre-commit. Als het 30–90 seconden duurt, verplaats het naar pre-push of draai het alleen wanneer bepaalde bestanden veranderen.\n\nTeams hebben ook een duidelijke houding nodig over handhaving. Voor een solo-repo kunnen opt-in hooks prima zijn. Voor een team-repo is het gebruikelijk de basics af te dwingen (secrets, formatting, commit message-regels) en zwaardere checks lokaal adviserend te houden, terwijl CI de uiteindelijke poort is.\n\nDe output van een hook doet er meer toe dan men denkt. Een hook die faalt moet zeggen wat er gebeurde en wat de volgende stap is. Houd berichten kort en specifiek. Toon waar mogelijk exact bestand en regel, geef één duidelijk fix-commando, leg uit hoe je alleen in echte noodgevallen kunt bypassen (en wanneer niet), en vermijd enorme logs tenzij de gebruiker om “verbose” vraagt.\n\nVoorbeeld: als je een project exporteert van Koder.ai en lokaal begint te committen, kan een snelle pre-commit hook een gekopieerd API-token direct vangen, terwijl pre-push de langzamere “alleen tests voor gewijzigde modules” regel draait voordat iemand de branch ziet.\n\n## Blokkeer secrets vóór ze gecommit worden\n\nEen secret is alles waarmee iemand als jou kan handelen of toegang krijgt tot private systemen. Denk aan API-tokens, OAuth client secrets, cloud keys, database-wachtwoorden, private webhook-URL's, signing keys en zelfs tijdelijke test-credentials. Eén per ongeluk commit kan in een fork, een CI-log of een geplakte diff belanden, en dan is het niet langer tijdelijk.\n\nDe makkelijkste winst is alleen scannen wat je op het punt staat te committen. Een hook moet staged changes (de index) controleren, niet je hele repo. Dat houdt het snel en voorkomt ruis van oude bestanden die je niet hebt aangeraakt. Het maakt de feedback ook eerlijker: “deze commit bevat een probleem” in plaats van “je repo had ooit een probleem.”\n\nVeelvoorkomende dingen om vroeg te markeren zijn hoog-entropie tokens (lange, willekeurig uitziende strings), bekende sleutel-formaten (AWS-keys, GitHub-tokens, JWTs), patronen zoals password=... of api_key: ... in config, private URL's met ingesloten credentials en .env-bestanden of gekopieerde productieconfiguraties.\n\nFalse positives gebeuren, vooral met testdata, hashes of voorbeelddocs. Bouw een allowlist in zodat mensen verder kunnen zonder de hele check uit te schakelen. Houd de allowlist smal: exacte bestandsmappen voor fixtures, of expliciete markers zoals “dummy” of “example” die je detector herkent.\n\nAls er een secret wordt gevonden, faalt de commit met een bericht dat vertelt wat te doen. Claude Code git hooks kunnen dit vriendelijker maken door een korte uitleg te geven op basis van de diff, maar de kern is duidelijke, veilige vervolgstappen:\n\ntext\nERROR: Possible secret detected in staged file: config/app.yaml (line 12)\nReason: looks like an API token\nNext steps:\n1) Remove it from the change or move it to env vars\n2) Rotate the token (assume it is compromised)\n3) Re-stage and retry commit\nIf this is a false positive, add a narrow allowlist rule in .secrets-allowlist\n\n\nEen concreet voorbeeld: iemand werkt een backendconfig bij en voegt een TEMP_API_KEY toe zodat een feature in dev werkt. De hook stopt de commit, suggereert verplaatsen naar een omgevingsvariabele en herinnert eraan te roteren als het echt was. Dat is een kleine onderbreking die een grote cleanup later voorkomt.\n\n## Formatting afdwingen zonder te vertragen\n\nFormatting kost reviewers tijd, maar trage hooks zijn een snelle manier om hooks uit te schakelen. De sweet spot is eenvoudige regels, één tool per taal en alleen wijzigen wat op het punt staat gecommit te worden.\n\nKies één formatter per taal en maak het de bron van waarheid. Twee formatteren die het niet eens zijn (of een formatter plus een linter die ook herschrijft) creëren lawaaierige diffs en eindeloze churn. Houd het saai: één JS/TS-formatter, één Go-formatter, één Dart-formatter. Zorg er daarna voor dat iedereen dezelfde versies draait zodat de hook-output stabiel is over machines heen.\n\nDe grootste snelheidswinst is alleen staged bestanden formatteren. Het formatteren van de hele repo bij elke commit is de belangrijkste reden waarom teams klagen over pre-commit. Een staged-only aanpak houdt de diff ook gefocust op wat je hebt veranderd, precies wat reviewers willen.\n\nEen praktische set keuzes die commits snel houdt:\n\n- Draai formatting op alleen staged bestanden.\n- Gebruik auto-fix voor veilige veranderingen (spaties, quotes, importorde).\n- Faalt snel wanneer een menselijke beslissing nodig is (zoals een regel die gedrag kan veranderen).\n- Houd formatter-output stil tenzij het iets veranderde.\n- Cache wanneer mogelijk, maar nooit ten koste van correctheid.\n\nAuto-fix versus falen is een teamvoorkeur, maar een gemengde aanpak werkt goed. Auto-fix is geweldig voor mechanische bewerkingen omdat het de “commit, fail, opnieuw draaien, opnieuw committen” lus vermijdt. Falen kan beter zijn wanneer je wilt dat mensen het probleem zien en een richting kiezen. Als je faalt, print dan één instructie die iedereen in 10 seconden kan volgen.\n\nStandaardiseer de kleine dingen die cross-platform-ruis veroorzaken. Line endings en trailing whitespace zijn de gebruikelijke boosdoeners, vooral wanneer mensen wisselen tussen Windows, macOS en CI.\n\nEen simpel beleid dat zelden pijn veroorzaakt:\n\n- Handhaaf LF line endings in de repo.\n- Verwijder trailing whitespace op gewijzigde regels.\n- Zorg dat bestanden eindigen met een newline.\n- Sla formatting over voor gegenereerde bestanden en vendor-mappen.\n\nWaar Claude Code git hooks bij kunnen helpen is in de lijm: detecteren welke staged bestanden welke formatter nodig hebben, ze in de juiste volgorde draaien en failures in gewone taal uitleggen. Bijvoorbeeld: als iemand een Go-bestand en een TS-bestand staged, kan de hook beide met de juiste tool formatteren, de resultaten re-stagen en dan kort melden “2 bestanden geformatteerd, geen gedragswijzigingen”. Reviewers zien schonere diffs en developers hebben niet het gevoel bestraft te worden voor vaak committen.\n\n## Vereis tests voor wat je veranderde\n\nEen eenvoudige regel maakt commits veiliger zonder pijnlijk te zijn: draai alleen de tests die passen bij wat je daadwerkelijk staged hebt. Wanneer de hook naar de staged diff kijkt (niet naar je working tree), vermijd je valse alarmen door half-afgemaakte bestanden.\n\nBegin met detecteren welke gebieden geraakt zijn. De meeste repos hebben al een natuurlijke structuur: packages, services, apps of modules. Een hook kan git diff --cached --name-only lezen en die paden mappen naar een klein set testcommando's.\n\nHier zijn een paar mappingregels die begrijpelijk blijven als je er later naar terugkeert:\n\n- web/ of frontend/ -\u003e run npm test (of het kleinste gerichte commando dat je hebt)\n- api/ of server/ -\u003e draai backend unit tests (sla integratie standaard over)\n- mobile/ -\u003e draai snelle widget/unit tests, geen volledige device suites\n- db/ of migrations/ -\u003e draai migration linting plus een kleine schema-check\n- shared/ -\u003e draai de shared package tests, plus eventuele snelle consumenten\n\nAls je Claude Code git hooks gebruikt, kun je nog een stap verder gaan: laat Claude naar de staged bestandsnamen kijken en een minimale testset voorstellen, waarna de hook die commando's uitvoert. Houd de uiteindelijke beslissingslogica echter regelgebaseerd, zodat het team kan voorspellen wat er gebeurt.\n\nVerdeel de workload tussen commit en push. Commits moeten snel blijven zodat mensen niet hooks gaan omzeilen. Een praktisch patroon is:\n\n- Bij commit: draai een snelle, selectieve set (lint + unit tests voor aangeraakte modules)\n- Bij push: draai een bredere set (integratie, end-to-end smoke, cross-module tests)\n- In CI: draai de volledige suite en handhaaf coverage-gates\n\nFlaky en langzame tests hebben een expliciet beleid nodig, anders wordt je hook ruis. Spreek als team af wat een commit blokkeert versus wat alleen waarschuwt. Een werkbare aanpak is blokkeren bij duidelijke fouten (formatting, unit tests die normaal stabiel zijn), waarschuwen bij bekende flaky tests met een kort bericht en langzame suites naar push/CI verplaatsen. Als een test flaky is, behandel dat als een bug: track, fix en verwijder de waarschuwingsmodus zodra het stabiel is.\n\n## Genereer korte reviewer-samenvattingen bij commit-tijd\n\nEen goede diff is niet altijd makkelijk te reviewen. Een korte commit-time samenvatting kan een 10-minuten leeswerk veranderen in een 2-minuten check, vooral wanneer wijzigingen meerdere bestanden raken of refactors bevatten.\n\nHet idee is simpel: wanneer je git commit draait, vraagt je hook aan Claude Code de staged diff te lezen en een notitie van 3 tot 6 regels te maken die de vragen beantwoordt die reviewers altijd hebben: wat is er veranderd, waarom, hoe risicovol is het en hoe is het getest.\n\n### Een eenvoudig samenvattingssjabloon\n\nHoud de output strak en consistent zodat reviewers het leren vertrouwen:\n\n- Wat: één zin over de belangrijkste wijziging (geen bestandlijst)\n- Waarom: het gebruikersprobleem of de bug die wordt opgelost\n- Risico: laag, midden of hoog met één reden\n- Testen: wat je draaide (of zeg “not run”)\n- Notities: migraties, flags, rollout stappen of alles wat review-kritisch is\n\nJe kunt dit direct in het commitbericht plaatsen (bijv. als korte footer), of opslaan in een bestand dat je team in de pull request-beschrijving plakt. Commit message werkt goed als je wilt dat de context met de wijziging meereist. Een apart bestand werkt beter als je team schone, conventionele commit subjects prefereert.\n\n### Leaks van secrets in de samenvatting voorkomen\n\nEen samenvattingstool moet strikter zijn dan een reviewer. Voordat je diff-inhoud naar het model stuurt, filter je lijnen die matchen op patronen zoals API-keys, private keys, tokens, .env-waarden en credentials. Filter ook veelvoorkomende headers en cookies als je repo vastgelegde HTTP-traffic bevat. Wanneer de hook gevoelige patronen detecteert, kan hij de lijnen redigeren of terugvallen op een generieke samenvatting zoals “credentials-related changes redacted”.\n\nVoorbeeld: je werkt een billing-endpoint bij en raakt drie bestanden aan. De staged diff is lawaaierig door renames, maar de samenvatting zegt: “Voegt idempotency key-afhandeling toe voor charge creation om dubbele facturering te voorkomen. Reden: retries veroorzaakten dubbele charges. Risico: medium (payment path). Testen: unit tests voor billing service, handmatige request replay.” Dat is precies wat een reviewer nodig heeft, zonder eerst elke regel te lezen.\n\n## Voorbeeld workflow: één commit, minder verrassingen\n\nJe lost een klein bugje op en past in dezelfde commit een config aan. De bug is een één-regelige wijziging in billing/tax.go. De configwijziging updatet config/staging.yaml om naar een nieuw endpoint te wijzen.\n\nJe draait git commit -am "Fix tax rounding". Je Claude Code git hooks schieten in en voeren een snelle set checks uit, in een voorspelbare volgorde.\n\nEerst kijkt de secret-scan naar wat veranderd is, niet naar je hele repo. Het markeert dat de staging-config iets bevat dat op een echte API-key lijkt.\n\ntext\nERROR: Possible secret detected in config/staging.yaml:12\nPattern: api_key=sk_live_...\nFix: remove the key and use an env var reference (e.g., API_KEY)\nOverride: set ALLOW_SECRETS=1 (not recommended)\n\n\nJe vervangt de waarde door een verwijzing naar een environment variable en commit weer.\n\nVervolgens draait formatting alleen waar het nodig is. Als je Go-bestand niet geformatteerd is, faalt het met een korte hint zoals “run gofmt on billing/tax.go”. Je draait de formatter en de hook slaagt binnen enkele seconden.\n\nDaarna draait de testgate een gerichte set. Omdat je billing/ hebt aangeraakt, draait hij alleen de billing unit tests (niet de volledige suite). Als een test faalt, toont de hook het exacte commando om lokaal te reproduceren. Je verhelpt het rounding-edgecase en draait opnieuw dezelfde tests.\n\nTot slot genereert de hook een reviewer-samenvatting uit de diff. Die is kort en specifiek, bijvoorbeeld:\n\n- What changed: Fix rounding in tax calculation for values ending in .005\n- Config: staging now reads API key from env var\n- Tests: billing unit tests passed\n- Risk: affects billing totals, but limited to tax rounding path\n\nWat de reviewer ziet is een commit die al schoon is: geen gelekte secrets, consistente formatting en tests die bij de wijziging passen. Ze krijgen ook een kant-en-klare samenvatting, zodat ze zich op de logica kunnen richten in plaats van intentie te zoeken.\n\n## Veelgemaakte fouten en hoe ze te vermijden\n\nDe snelste manier om hooks te doen falen is ze pijnlijk maken. Als een hook lang genoeg duurt om iemands flow te breken, zullen mensen hem omzeilen met --no-verify of hem verwijderen. Houd alles zware uit pre-commit en draai het in CI of op aanvraag.\n\nEen praktische regel: pre-commit moet voelen als een spellingscontrole, niet als een test-suite. Als je slimmer checks van Claude Code wilt, gebruik ze om te beslissen wat te draaien, niet om alles te draaien.\n\n### 1) Hooks die te traag zijn\n\nMaak hooks standaard snel en streng alleen wanneer nodig. Bijvoorbeeld: draai snelle format + secret scan bij elke commit, maar tests alleen voor aangeraakte modules.\n\nEen eenvoudig snelheidsbudget dat goed werkt:\n\n- pre-commit: 1 tot 5 seconden totaal\n- commit-msg: onder 1 seconde\n- Alles wat langer is: verplaats naar pre-push of CI\n\n### 2) AI-output zonder duidelijke regels\n\nAI is geweldig voor suggesties, niet voor beleid. Als je een AI vraagt de diff te “reviewen” zonder regels, krijg je elke keer verschillende resultaten. Definieer wat de hook moet doen (en wat hij nooit mag doen). Bijvoorbeeld: hij kan een reviewer-samenvatting genereren, maar hij mag geen code herschrijven tenzij een formatter al deterministische veranderingen produceerde.\n\n### 3) Staged versus unstaged verwarring\n\nVeel hooks scannen per ongeluk je working tree en falen de commit vanwege veranderingen die je niet staged had. Dat voelt oneerlijk.\n\nVermijd dit door altijd staged content als input te gebruiken. Een goede test: wijzig een bestand, stage slechts de helft en verifieer dat de hook alleen meldt wat gestaged is.\n\n### 4) Te veel false positives\n\nAls elke commit een waarschuwing triggert, worden waarschuwingen ruis. Tweak patronen, voeg allowlists toe voor bekende veilige strings en degradeer “misschien”-bevindingen naar een waarschuwing met een duidelijke fix.\n\nConcreet voorbeeld: als je secret scanner test-keys in fixtures/ flagt, voeg dan een regel toe om die map te negeren, maar blijf echte keys in app-configs blokkeren.\n\n## Snelle checklist en volgende stappen\n\nAls je Claude Code git hooks wilt laten helpen zonder je team te irriteren, is het doel simpel: vang echte problemen vroeg, blijf stil als alles normaal is en houd de commit-lus snel.\n\nEen praktische checklist die voor de meeste repos werkt:\n\n- Houd pre-commit onder een paar seconden voor de meeste wijzigingen. Als het traag wordt, zullen mensen het omzeilen.\n- Scan, format en lint alleen staged bestanden. Alles anders hoort in pre-push of CI.\n- Blokkeer duidelijke secrets (API-keys, private keys, tokens). Voor “misschien”-gevallen: waarschuw en laat de ontwikkelaar bevestigen.\n- Vereis gerichte tests bij commit voor aangeraakte modules, en draai bredere tests bij push of CI.\n- Voeg een korte, consistente commit-samenvatting toe zodat reviewers weten wat veranderd is en waar ze op moeten letten.\n\nEen kleine detail die veel oplevert: zorg dat de reviewer-samenvatting elke keer hetzelfde eruitziet. Een simpel sjabloon is genoeg en traint reviewers snel te scannen.\n\ntext\nReview summary:\n- What changed: <1-2 bullets>\n- Risky areas: <files/modules>\n- Tests run: <command or “not run + why”>\n\n\nVolgende stappen die adoptie eenvoudig houden:\n\n- Prototypeer de flow eerst in een sandbox-project en kopieer het naar de echte repo zodra het goed voelt.\n- Begin met “warn only” modus voor een week, meet false positives en schakel daarna de meest betrouwbare checks naar “block”.\n- Voeg escape-hatches toe voor noodgevallen (bijvoorbeeld: allow skip van een hook met een duidelijke reden in het commitbericht) en log wanneer dit gebeurt.\n- Verplaats alles zwaars (volle test-suites, diepe secret-scans, dependency audits) naar pre-push of CI zodat commits snel blijven.\n\nAls je graag tooling bouwt in een chat-first manier, kan Koder.ai (koder.ai) handig zijn om de kleine helper-scripts rond je hooks te genereren en veilig te itereren met snapshots en rollback voordat je de broncode exporteert naar je repo.