Les Git Hooks, ça vous parle ? Ou peut-être que vous préférez voir la CI casser à chaque commit parce que le dev n'a pas testé sur son poste ?
Protéger ses branches, c'est bien. Protéger sa CI aussi. Mais on peut aller encore plus vite : en obligeant le développeur à tester son application, même malgré lui.
Un hook, c'est quoi au juste
Un Git Hook est un script que Git déclenche automatiquement à un moment précis du cycle de vie d'un dépôt : avant un commit (pre-commit), avant de rédiger le message (prepare-commit-msg), avant un push (pre-push), après un merge (post-merge)… Le plus utile au quotidien est le pre-commit : il s'exécute juste avant que le commit ne soit enregistré, et s'il échoue, le commit n'a pas lieu.
L'idée tient en une phrase : au moment du commit, paf, un script se lance pour tout tester. Lint, typecheck, tests unitaires — ce que vous voulez. Si quelque chose casse, le commit est refusé et le dev corrige avant que le code ne parte sur la branche.
Pourquoi ça accélère vos déploiements
Sans hook, le scénario classique est connu : le dev commit, push, et c'est la CI qui découvre que les tests cassent — dix minutes plus tard, avec un pipeline rouge et un aller-retour de plus. Avec un pre-commit, l'erreur est attrapée sur le poste, en quelques secondes, avant même de quitter la machine.
Un Git Hook pre-commit qui lance les tests transforme la CI en confirmation plutôt qu'en découverte : le code qui arrive sur la branche a déjà passé les tests localement, donc le pipeline casse beaucoup moins souvent. Moins d'allers-retours, des déploiements plus rapides.
On ne retire pas la CI pour autant
Attention au contresens : le hook ne remplace pas la CI. D'abord parce qu'un hook, c'est bypassable — un --no-verify et il saute. Ensuite parce qu'il tourne dans l'environnement du dev, qui n'est pas l'environnement de référence : versions différentes, variables d'env locales, dépendances pas tout à fait à jour.
Le hook et la CI ne jouent donc pas le même rôle : le hook est un filet rapide côté développeur qui attrape la majorité des erreurs avant le push ; la CI reste l'autorité finale, dans un environnement propre et non contournable. C'est un p'tit truc en plus qui sécurise votre code et accélère vos déploiements — pas un substitut.
Bien entendu… pour que tout ça serve à quelque chose, encore faut-il que vos projets aient des tests à lancer 🙂.
Avec Singularity, la mise en place est simplifiée
Écrire un hook à la main reste ingrat : il faut connaître le bon nom de fichier, le rendre exécutable, gérer le runtime (Husky, scripts maison…), et ne pas se tromper dans le shell. C'est précisément ce qui fait que les hooks sont si peu utilisés alors qu'ils sont si puissants.
Dans Singularity, un menu dédié dans l'interface Git donne directement accès aux hooks. Vous voyez la liste complète — pre-commit, prepare-commit-msg, commit-msg, post-commit, pre-rebase, pre-push… — le runtime détecté (Husky, par exemple), et le contenu de chaque script, modifiable sur place.
pre-commit ouvert à droite, prêt à être édité.Et si l'écriture du shell vous rebute : laissez l'IA le générer
Le vrai blocage, pour beaucoup, ce n'est pas l'idée du hook — c'est d'écrire le script. Singularity lève ce frein : vous décrivez ce que vous voulez en langage naturel — « lance les tests avant chaque commit et refuse-le si un test échoue » — et un agent IA génère le hook pour vous.
Vous obtenez un script lisible et versionné, que vous gardez la main d'éditer ou d'affiner. Si vous êtes frileux avec les Git Hooks, c'est exactement le coup de pouce qui vous fait franchir le pas : la protection d'un pre-commit sans avoir à écrire une ligne de shell.
En résumé
Protéger ses branches, protéger sa CI, et — en plus — forcer les tests au commit avec un Git Hook : trois filets qui se complètent. Le hook accélère parce qu'il attrape l'erreur au plus tôt ; la CI reste l'autorité finale parce qu'elle n'est pas contournable. Singularity vous donne le menu pour gérer vos hooks, et l'IA pour les écrire à votre place.
Ça vous intrigue ? Venez le tester. C'est gratuit.
Foire aux questions
Qu'est-ce qu'un Git Hook pre-commit ?
C'est un script que Git exécute automatiquement juste avant d'enregistrer un commit. On y place en général le lint, le typecheck et les tests : si l'un d'eux échoue, le commit est refusé et le développeur corrige avant que le code ne parte sur la branche. C'est le filet de sécurité le plus utile au quotidien.
Un Git Hook remplace-t-il la CI ?
Non. Un hook est bypassable (par exemple avec --no-verify) et tourne dans l'environnement du développeur, qui n'est pas l'environnement de référence. Il attrape la majorité des erreurs avant le push et accélère les déploiements, mais la CI reste l'autorité finale, dans un environnement propre et non contournable. Les deux sont complémentaires.
Comment Singularity aide-t-il à mettre en place les hooks ?
Singularity propose un menu dédié dans son interface Git : il liste tous les hooks (pre-commit, pre-push, commit-msg…), détecte le runtime utilisé (Husky par exemple) et affiche le contenu de chaque script, modifiable sur place. Plus besoin de chercher le bon fichier ou de gérer le runtime à la main.
Peut-on faire générer un Git Hook par l'IA dans Singularity ?
Oui. Vous décrivez en langage naturel ce que le hook doit faire — par exemple « lance les tests avant chaque commit et refuse-le si un test échoue » — et un agent IA génère le script pour vous. Vous obtenez un hook lisible et versionné que vous restez libre d'éditer. C'est utile si vous êtes frileux avec l'écriture de shell.
Faut-il des tests pour qu'un hook pre-commit serve à quelque chose ?
Oui. Un hook qui lance les tests n'a d'intérêt que si le projet a effectivement des tests à exécuter. Sans tests, le hook peut toujours lancer le lint et le typecheck, mais l'essentiel de la protection vient de la suite de tests. Avoir des tests reste le pré-requis.