Les hooks Git Claude Code peuvent empêcher les fuites de secrets, appliquer le formatage, lancer les bons tests et rédiger de courts résumés de commit pour accélérer les revues.
La plupart des frictions en revue ne viennent pas du « code dur ». Elles viennent d'erreurs évitables qui se glissent dans un commit : un flag de debug laissé, un fichier non formaté qui crée des diffs bruyants, un test non mis à jour, ou un secret copié dans une config. Chacun est petit, mais ensemble ils transforment une revue propre en un va-et-vient lent.
L'automatisation au moment du commit est l'endroit le plus simple pour arrêter ça. Quand des vérifications s'exécutent juste avant la création d'un commit, elles attrapent les problèmes tant que le changement est encore frais dans votre tête. Corriger une erreur prend quelques secondes parce que vous êtes déjà dans le contexte du travail. Comparez cela à la découverte du problème deux jours plus tard dans une pull request, après que d'autres commits se soient accumulés et que le relecteur doive demander ce qui s'est passé.
Les hooks Git sont un outil pratique pour cela parce qu'ils s'exécutent localement, sans attendre la CI. Mais ce n'est pas de la magie. Les hooks peuvent être contournés, mal configurés ou incohérents entre machines si votre équipe ne les standardise pas. Ils ne garantissent pas non plus la qualité à eux seuls. Considérez-les comme des garde-corps, pas des barrières.
Là où les hooks aident le plus, c'est pour prévenir la « taxe de revue », le feedback répétitif et à faible valeur qui revient sans cesse. Exemples courants : chaînes sensibles ressemblant à des tokens, bruit de formatage et lint, vérifications basiques « avez-vous lancé les bons tests ? », et petits résumés de contexte qui aident un relecteur à comprendre l'intention.
C'est là que les Claude Code git hooks s'insèrent bien : ils peuvent faire le travail de vérification ennuyeux et ajouter un peu de contexte lisible par l'humain au moment précis du commit.
Poser des attentes compte. Gardez les hooks locaux rapides et prévisibles pour que les gens ne les détestent pas. Les vérifications rapides appartiennent à votre laptop ; les vérifications lentes viennent plus tard. Une bonne séparation est : secondes au moment du commit et minutes en CI. Si un hook prend régulièrement assez de temps pour que quelqu'un utilise « skip », il cesse de protéger votre repo.
Un exemple simple : vous modifiez un module et refactorez deux fonctions. Sans automatisation, un relecteur voit 400 lignes déplacées, aucun test mentionné, et doit poser des questions de base. Avec des vérifications au commit, le commit est formaté, un ensemble de tests pertinent a été lancé, et le message de commit inclut un court résumé. La revue commence là où elle devrait : sur la conception, pas sur le nettoyage.
Les hooks Git sont excellents pour des vérifications simples, mais ils s'arrêtent généralement à des règles oui/non : « le fichier est-il formaté ? » ou « avez-vous lancé le linter ? ». Claude Code peut ajouter une couche légère de jugement en lisant votre diff staged et quelques fichiers liés, puis en prenant des décisions qui correspondent mieux à la façon dont les humains examinent les changements.
Avec les Claude Code git hooks, le hook peut regarder ce que vous avez réellement changé, pas seulement ce qui existe dans le repo. Ça rend l'automatisation plus sélective. Elle peut se concentrer sur les modules touchés, les fichiers de config modifiés et les nouvelles variables d'environnement, au lieu de traiter chaque commit comme une build complète.
Tâches pratiques où « lire le diff et réfléchir » rapporte :
Les contraintes comptent parce qu'un hook lent devient un hook ignoré. Gardez l'objectif petit : ajoutez des garde-fous qui attrapent les erreurs courantes tôt, pas un second système CI à chaque commit.
Une bonne règle : si ça ne peut pas finir en quelques secondes, ça appartient probablement en CI ou en pre-push. Beaucoup d'équipes lancent des vérifications locales rapides au commit et laissent les suites de tests plus lourdes pour plus tard.
Prévoyez les modes d'échec. Si un appel modèle time-out, décidez s'il doit bloquer le commit ou revenir à une vérification plus simple. Un mécanisme de secours garde le flux prévisible et évite d'habituer les gens à désactiver les hooks.
Certaines configurations appellent un modèle hébergé ; d'autres s'exécutent dans un environnement plus isolé. Décidez quel code peut quitter la machine du développeur (si c'est le cas), et limitez ce que vous envoyez. Le diff staged plus un petit ensemble de fichiers référencés suffit souvent.
Si vous travaillez avec des dépôts sensibles, soyez explicite sur l'endroit où l'analyse s'exécute et ce qui est journalisé. Exemple concret : si un commit ajoute une nouvelle valeur de config comme STRIPE_SECRET=..., le hook peut arrêter le commit, expliquer ce qui semble risqué, et suggérer de le déplacer vers un gestionnaire de secrets ou un fichier env local avant qu'il n'atteigne le repo distant.
Les hooks Git ne sont utiles que si les gens les laissent activés et n'apprennent pas à craindre les commits. L'astuce est de choisir le bon hook pour la bonne tâche et d'exclure tout ce qui est lent du chemin critique.
Une carte simple d'où les vérifications appartiennent généralement :
Quand vous ajoutez des Claude Code git hooks, traitez-les comme un relecteur utile qui arrive instantanément, pas comme un goulot d'étranglement. Placez tout ce qui nécessite des appels réseau, des suites complètes de tests ou une analyse longue en pre-push ou en CI, pas en pre-commit.
Une manière pratique de décider ce qui s'exécute où est de trier les vérifications par rapidité et impact. Si ça attrape des problèmes à haut risque (comme des clés fuitées) et que ça peut s'exécuter en une ou deux secondes, ça appartient en pre-commit. Si ça prend 30 à 90 secondes, déplacez-le en pre-push ou exécutez-le seulement quand certains fichiers changent.
Les équipes ont aussi besoin d'une position claire sur l'application. Pour un repo solo, des hooks opt-in peuvent suffire. Pour un repo d'équipe, il est courant d'appliquer le minimum (secrets, formatage, règles de message de commit) et de garder localement les vérifications plus lourdes en mode consultatif, la CI restant la porte finale.
La sortie d'un hook compte plus que l'on croit. Un hook qui échoue doit dire ce qui s'est passé et quoi faire ensuite. Gardez les messages courts et spécifiques. Montrez le fichier et la ligne exacts quand c'est possible, donnez une commande de correction claire, expliquez comment contourner uniquement pour les urgences réelles (et quand ne pas le faire), et évitez les logs énormes sauf si l'utilisateur demande le mode « verbose ».
Exemple : si vous exportez un projet depuis Koder.ai et commencez à committer localement, un pre-commit rapide peut attraper immédiatement un token API copié, tandis que le pre-push exécute la règle plus lente « seuls les tests pour les modules changés » avant que quelqu'un d'autre voie la branche.
Un secret est tout ce qui permet à quelqu'un d'agir comme vous ou d'accéder à des systèmes privés. Pensez aux tokens API, secrets OAuth, clés cloud, mots de passe de base de données, URLs privées avec identifiants, clés de signature, et même aux identifiants temporaires de test. Un commit accidentel peut finir dans un fork, un log CI, ou un diff collé, et alors il ne sera plus temporaire.
Le gain le plus simple est de scanner uniquement ce que vous êtes sur le point de committer. Un hook doit vérifier les changements staged (l'index), pas tout votre repo. Cela le rend rapide et évite le bruit des anciens fichiers que vous n'avez pas touchés. Cela rend aussi le retour plus juste : « ce commit inclut un problème » au lieu de « votre repo a eu un problème ».
Les choses courantes à signaler tôt incluent des tokens à haute entropie (chaînes longues ressemblant à du hasard), des formats de clés connus (clés AWS, tokens GitHub, JWT), des patterns comme password=... ou api_key: ... dans la config, des URLs privées avec identifiants embarqués, et des fichiers .env ou des configs de production copiées.
Les faux positifs arrivent, notamment avec des données de test, des hash ou de la documentation d'exemple. Ajoutez une allowlist pour que les gens puissent avancer sans désactiver la vérification entière. Gardez l'allowlist étroite : chemins de fichiers exacts pour les fixtures, ou marqueurs explicites comme « dummy » ou « example » que votre détecteur reconnaît.
Quand un secret est trouvé, échouez le commit avec un message qui indique la marche à suivre. Les Claude Code git hooks peuvent rendre ceci plus convivial en produisant une courte explication basée sur le diff, mais l'essentiel est d'indiquer des actions claires et sûres :
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
Exemple concret : quelqu'un met à jour une config backend et ajoute une TEMP_API_KEY pour qu'une fonctionnalité fonctionne en dev. Le hook stoppe le commit, suggère de la déplacer vers une variable d'environnement, et rappelle de la faire tourner si c'était une vraie clé. C'est une petite interruption qui évite un gros nettoyage plus tard.
Les disputes sur le formatage font perdre du temps aux relecteurs, mais des hooks lents sont le moyen le plus rapide d'obtenir des hooks désactivés. La solution idéale est des règles simples, un outil par langage, et ne toucher qu'à ce qui est sur le point d'être committé.
Choisissez un seul formateur par langage et faites-en la source de vérité. Deux formateurs qui divergent (ou un formateur plus un linter qui réécrit aussi) créeront des diffs bruyants et des frictions sans fin. Restez ennuyeux : un formateur JS/TS, un formateur Go, un formateur Dart. Puis assurez-vous que tout le monde utilise les mêmes versions pour que la sortie du hook soit stable entre machines.
Le plus grand gain de vitesse est de formater uniquement les fichiers staged. Formater tout le repo à chaque commit est la principale raison des plaintes sur pre-commit. L'approche staged garde aussi le diff centré sur ce que vous avez changé, ce que veulent exactement les relecteurs.
En pratique :
Auto-fix vs échouer est une préférence d'équipe, mais une approche mixte marche bien. L'auto-fix évite la boucle « commit, fail, relancer, commit à nouveau ». L'échec peut être préférable quand vous voulez que les gens voient le problème et choisissent une direction. Si vous échouez, imprimez une instruction que n'importe qui peut suivre en 10 secondes.
Standardisez les petites choses qui causent du bruit inter-plateformes. Fin de ligne et espaces en fin de ligne sont les coupables habituels, surtout quand on change entre Windows, macOS et CI.
Une politique simple qui cause peu de problèmes :
Où Claude Code git hooks peuvent aider : faire le lien : détecter quels fichiers staged ont besoin de quel formateur, les exécuter dans le bon ordre, et expliquer les échecs en langage simple. Par exemple, si quelqu'un stage un fichier Go et un fichier TS, le hook peut formater chacun avec l'outil adapté, re-stage les résultats, puis afficher une courte note comme « 2 fichiers reformatés, pas de changement de comportement ». Les relecteurs voient des diffs plus propres, et les développeurs ne se sentent pas punis pour committer souvent.
Une règle simple rend les commits plus sûrs sans les rendre pénibles : n'exécuter que les tests qui correspondent à ce que vous avez effectivement staged. Quand le hook regarde le diff staged (pas votre working tree), il évite les faux positifs dus à des fichiers à moitié terminés.
Commencez par détecter quelles zones ont été touchées. La plupart des repos ont déjà une structure naturelle : packages, services, apps ou modules. Un hook peut lire git diff --cached --name-only, puis mapper ces chemins à un petit ensemble de commandes de test.
Quelques règles de mapping compréhensibles plus tard :
web/ ou frontend/ -> exécuter npm test (ou la commande la plus ciblée que vous avez)api/ ou server/ -> exécuter les tests unitaires backend (sauter l'intégration par défaut)mobile/ -> exécuter des tests unitaires/rapid widget, pas les suites device complètesdb/ ou migrations/ -> exécuter un lint des migrations plus une petite vérification de schémashared/ -> exécuter les tests du package partagé, plus les consommateurs rapidesAvec Claude Code git hooks, vous pouvez aller plus loin : faire regarder Claude aux noms de fichiers staged et proposer un jeu minimal de tests, puis le hook exécute ces commandes. Gardez cependant la règle finale basée sur des règles déterministes, afin que l'équipe puisse prédire ce qui va se passer.
Répartissez la charge entre commit et push. Les commits doivent rester rapides pour éviter que les gens contournent les hooks. Un modèle pratique :
Les tests instables et lents nécessitent une politique explicite, sinon votre hook devient du bruit. Mettez-vous d'accord en équipe sur ce qui bloque un commit vs ce qui avertit seulement. Approche viable : bloquer sur des échecs clairs (formatage, tests unitaires normalement stables), avertir sur les tests connus instables avec un message court, et déplacer les suites lentes vers push/CI. Si un test est instable, traitez cela comme un bug : suivez-le, réparez-le et retirez le mode avertissement dès qu'il est stable.
Un bon diff n'est pas toujours facile à relire. Un court résumé généré au commit peut transformer une lecture de 10 minutes en une vérification de 2 minutes, surtout quand les changements touchent plusieurs fichiers ou comprennent des refactors.
L'idée est simple : quand vous lancez git commit, votre hook demande à Claude Code de lire le diff staged et de produire une note de 3 à 6 lignes qui répond aux questions que les relecteurs se posent toujours : ce qui a changé, pourquoi, à quel point c'est risqué, et comment ça a été testé.
Gardez la sortie concise et cohérente pour que les relecteurs apprennent à lui faire confiance :
Vous pouvez mettre cela directement dans le message de commit (par ex. en footer), ou le sauvegarder dans un fichier que votre équipe colle dans la description de PR. Le message de commit marche bien quand vous voulez que le contexte suive le changement. Un fichier séparé marche mieux si l'équipe préfère des sujets de commit propres et conventionnels.
Un outil de résumé doit être plus strict qu'un relecteur humain. Avant d'envoyer du contenu de diff à un modèle, filtrez les lignes qui correspondent à des patterns comme clés API, clés privées, tokens, valeurs .env et identifiants. Filtrez aussi les headers et cookies courants si votre repo inclut du trafic HTTP capturé. Quand le hook détecte des patterns sensibles, il peut masquer les lignes ou basculer sur un résumé générique comme « modifications liées aux identifiants masquées ».
Exemple : vous mettez à jour un endpoint de facturation et touchez trois fichiers. Le diff staged est bruyant à cause de renommages, mais le résumé dit : « Ajoute la gestion des idempotency keys pour la création de charge afin d'éviter la double facturation. Raison : les retries causaient des duplications. Risque : moyen (chemin de paiement). Tests : tests unitaires du service de facturation, replay manuel. » C'est exactement ce dont un relecteur a besoin, sans lire chaque ligne d'abord.
Vous corrigez un petit bug et modifiez une config dans le même commit. Le bug est un changement d'une ligne dans billing/tax.go. La modification de config met à jour config/staging.yaml pour pointer vers un nouvel endpoint.
Vous exécutez git commit -am "Fix tax rounding". Vos Claude Code git hooks se déclenchent et effectuent une série de vérifications rapides, dans un ordre prévisible.
D'abord, le scan de secrets regarde ce qui a changé, pas tout votre repo. Il signale que la config staging contient quelque chose qui ressemble à une vraie clé 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)
Vous remplacez la valeur par une référence de variable d'environnement, puis vous committez à nouveau.
Ensuite, le formatage s'exécute uniquement où c'est pertinent. Si votre fichier Go n'est pas formaté, il échoue avec un court indice du type « lancer gofmt sur billing/tax.go ». Vous lancez le formatter, et le hook passe en quelques secondes.
Puis la porte de tests exécute un ensemble ciblé. Comme vous avez touché billing/, elle lance seulement les tests unitaires de billing (pas la suite complète). Si un test échoue, le hook affiche la commande exacte pour reproduire localement. Vous corrigez le cas de l'arrondi et relancez les mêmes tests.
Enfin, le hook génère un résumé pour le relecteur à partir du diff. Il est court et spécifique, par exemple :
Ce que le relecteur voit est un commit déjà propre : pas de secrets fuités, formatage cohérent, et tests correspondant au changement. Il reçoit aussi un résumé prêt à l'emploi, pour se concentrer sur la logique au lieu de chercher l'intention.
Le moyen le plus rapide de faire échouer des hooks est de les rendre pénibles. Si un hook prend assez de temps pour briser le flux de quelqu'un, les gens le contourneront avec --no-verify ou le supprimeront. Gardez tout ce qui est lourd hors de pre-commit et exécutez-le en CI ou à la demande.
Règle pratique : pre-commit doit ressembler à une vérification de typo, pas à une suite de tests. Si vous voulez des vérifications plus intelligentes avec Claude Code git hooks, utilisez-les pour décider quoi lancer, pas pour tout lancer.
Rendez les hooks rapides par défaut et stricts seulement quand il le faut. Par exemple, lancez format + scan de secrets rapides à chaque commit, mais exécutez les tests seulement pour les modules affectés.
Budget de temps simple qui fonctionne bien :
pre-commit : 1 à 5 secondes au totalcommit-msg : < 1 secondepre-push ou CIL'IA est excellente pour des suggestions, pas pour la politique. Si vous demandez à une IA de « revoir le diff » sans règles, vous obtenez des résultats variables. Définissez ce que le hook doit faire (et ce qu'il ne doit jamais faire). Par exemple : il peut générer un résumé, mais il ne peut pas réécrire le code sauf si un formateur a déjà produit des changements déterministes.
Beaucoup de hooks scannent par erreur votre working tree, puis font échouer le commit à cause de changements que vous n'avez pas staged. Ça paraît injuste.
Évitez-le en utilisant toujours le contenu staged comme entrée. Bon test : éditez un fichier, stagez seulement la moitié, et vérifiez que le hook ne signale que ce qui est staged.
Si chaque commit déclenche un avertissement, les avertissements deviennent du bruit. Ajustez les patterns, ajoutez des allowlists pour les chaînes sûres connues, et rétrogradez les détections « peut-être » en avertissement avec une correction claire.
Exemple concret : si votre scanner de secrets signale des clés de test dans fixtures/, ajoutez une règle pour ignorer ce dossier, mais continuez à bloquer les vraies clés dans les fichiers de config applicatifs.
Si vous voulez que les Claude Code git hooks aident sans agacer votre équipe, l'objectif est simple : attraper les vrais problèmes tôt, rester discret quand tout va bien, et garder la boucle de commit rapide.
Checklist pratique qui marche pour la plupart des repos :
pre-commit sous quelques secondes pour la plupart des changements. Si ça devient lent, les gens le contourneront.pre-push ou CI.Un petit détail qui rapporte : faites en sorte que le résumé pour le relecteur ait toujours la même apparence. Un modèle simple suffit, et il habitue les relecteurs à scanner rapidement.
Review summary:
- What changed: <1-2 bullets>
- Risky areas: <files/modules>
- Tests run: <command or “not run + why”>
Prochaines étapes faciles à adopter :
pre-push ou CI pour que les commits restent rapides.Si vous aimez construire des outils de façon chat-first, Koder.ai (koder.ai) peut être pratique pour générer les petits scripts d'aide autour de vos hooks et itérer en toute sécurité avec snapshots et rollback avant d'exporter le code source dans votre repo.
Commencez par les récidivistes qui gaspillent le temps des relecteurs :
Gardez tout ce qui est lent (suite complète de tests, analyse statique profonde) pour pre-push ou CI.
Un bon défaut est :
pre-commit pour des vérifications rapides qui regardent les changements staged (secrets, formatage, lint rapide, tests unitaires sélectifs)commit-msg pour les règles sur le message de commit (longueur, format, ID de ticket)pre-push pour des vérifications plus lentes mais toujours locales (tests plus larges, builds)Si une vérification prend régulièrement plus de quelques secondes, déplacez-la plus loin.
Considérez les hooks au moment du commit comme des garde-fous, pas comme votre unique enforcement.
Politique pratique : les hooks aident les développeurs ; la CI protège la branche principale.
Scannez le diff staged (l'index), pas tout le repo.
Si vous avez besoin d’un scan sur tout le repo, exécutez-le sur un programme planifié ou en CI.
Bloquez quand la correspondance est à haute confiance (formats de clés réels, blocs de clés privées, valeurs password= évidentes dans la config). Avertissez quand c’est ambigu.
Ajoutez aussi une allowlist étroite pour les cas sûrs connus, tels que :
DUMMY_KEY)Si les gens voient des faux positifs constants, ils désactiveront le hook.
Formatez uniquement les fichiers staged, et utilisez un seul formateur par langage.
Defaults pratiques :
Cela garde les diffs propres sans transformer chaque commit en réécriture longue.
Mappez les chemins modifiés à un petit ensemble de commandes de test rapides.
Approche exemple :
git diff --cached --name-onlypre-push ou CIÇa garde les commits rapides tout en attrapant tôt les régressions les plus courantes.
Restez concis et consistant (3–6 lignes). Un modèle simple :
Vous pouvez l’ajouter au message de commit ou le produire comme sortie texte pour la description de PR.
Rédigez avant d’envoyer quoi que ce soit à un modèle et soyez conservateur.
.env, clés privées, cookies, ou en-têtes d’auth.Par défaut, « partagez moins », surtout dans les dépôts privés.
Rendez les hooks prévisibles et rapides :
pre-commit)Si le hook semble instable ou lent, les développeurs utiliseront .
--no-verify