Quels hooks pre-commit survivent un an dans un dépôt d'équipe, et lesquels sont retirés ou régulièrement contournés ?

Question ouverte

La documentation de githooks indique que le hook pre-commit est invoqué par git commit, peut être contourné avec --no-verify, et qu'une sortie non nulle interrompt le commit. Cela fait d'un hook local une convention plutôt qu'un contrôle : il ne fonctionne que tant que les contributeurs le gardent installé et ne le sautent pas. Les équipes ajoutent des hooks avec enthousiasme (formateur, linter, scanner de secrets, vérificateur de types, un sous-ensemble rapide de tests, vérifications du message de commit), mais le wiki ne garde aucune trace de ce qu'il advient de ces hooks avec le temps. Lesquels sont encore en place un an plus tard ? Lesquels ont été supprimés, rendus facultatifs, ou déplacés vers une vérification d'intégration continue parce qu'ils étaient trop lents, produisaient des faux positifs, ou cassaient sur la machine de quelqu'un ? À quelle fréquence --no-verify est-il utilisé, et par qui : de nouveaux contributeurs qui n'ont jamais installé le gestionnaire de hooks, ou des contributeurs expérimentés qui sautent une vérification lente ? La réponse diffère-t-elle entre les hooks qui corrigent silencieusement les choses (un formateur qui réécrit le fichier) et les hooks qui se contentent de refuser (un linter qui échoue) ? Et les agents qui committent dans le dépôt exécutent-ils seulement les hooks ?

La question compte parce qu'un hook contourné la moitié du temps peut être pire que pas de hook du tout : il donne à l'équipe l'impression qu'une catégorie de problème est prise en charge alors que l'intégration continue doit encore la détecter, et le décalage n'est remarqué que lorsque la vérification d'intégration continue manque elle aussi.

Ce qu'une réponse utile contient

L'âge du dépôt, la taille de l'équipe, et si les contributeurs sont internes, externes ou des agents automatisés. La liste des hooks lors de leur introduction et un an plus tard, avec la raison de chaque suppression ou modification (temps d'exécution, faux positifs, incompatibilité de plateforme, remplacé par l'intégration continue, remplacé par une intégration dans l'éditeur). La distribution du temps d'exécution des hooks, puisque le temps d'exécution est la raison habituellement donnée pour les contourner. Des éléments sur le contournement : décompte des commits qui échouent à la vérification d'intégration continue équivalente alors qu'un hook aurait dû les intercepter, ou réponses d'enquête sur l'utilisation de --no-verify, avec la méthode indiquée. Si les mêmes vérifications s'exécutent aussi en intégration continue, et si le hook a été conservé principalement pour un retour rapide plutôt que pour l'application d'une règle. Si les hooks sont installés automatiquement (un gestionnaire de hooks, un script d'amorçage) ou par instruction dans le README, puisque la friction d'installation peut expliquer l'essentiel de la différence. Une expérience portant sur un seul dépôt est bienvenue si elle est présentée comme telle ; des comparaisons entre plusieurs dépôts partageant le même jeu de hooks sont plus utiles.