¿Qué hooks de pre-commit siguen en uso tras un año en un repositorio de equipo y cuáles se eliminan o se omiten de forma habitual?

Pregunta abierta

La documentación de githooks indica que git commit invoca el hook pre-commit, que se puede omitir con --no-verify y que una salida distinta de cero cancela el commit. Esto convierte al hook local en una convención y no en un control: funciona solo mientras los colaboradores lo mantengan instalado y no lo salten. Los equipos añaden hooks con entusiasmo (formateador, linter, escáner de secretos, verificador de tipos, un subconjunto rápido de pruebas, comprobaciones del mensaje de commit), pero la wiki no tiene ningún registro de lo que ocurre con esos hooks con el paso del tiempo. ¿Cuáles siguen vigentes un año después? ¿Cuáles se eliminaron, se hicieron opcionales o se movieron a una comprobación de CI porque eran demasiado lentos, producían falsos positivos o fallaban en la máquina de alguien? ¿Con qué frecuencia se usa --no-verify y quién lo hace: colaboradores nuevos que nunca instalaron el gestor de hooks o colaboradores con experiencia que se saltan una comprobación lenta? ¿Difiere la respuesta entre los hooks que corrigen en silencio (un formateador que reescribe el archivo) y los que solo rechazan (un linter que falla)? Y los agentes que hacen commits en el repositorio, ¿ejecutan los hooks siquiera?

La pregunta importa porque un hook que se omite la mitad de las veces puede ser peor que no tener ninguno: da al equipo la impresión de que una clase de problemas está cubierta, aunque CI todavía tiene que detectarlos, y el desajuste solo se descubre cuando tampoco existe la comprobación en CI.

Qué contiene una respuesta útil

La antigüedad del repositorio, el tamaño del equipo y si los colaboradores son internos, externos o agentes automatizados. La lista de hooks en el momento de su introducción y un año después, con el motivo de cada eliminación o cambio (tiempo de ejecución, falsos positivos, fallos según la plataforma, sustitución por CI, sustitución por integración con el editor). La distribución de los tiempos de ejecución de los hooks, ya que el tiempo de ejecución es el motivo que se suele dar para omitirlos. Datos sobre las omisiones: recuentos de commits que no pasan la comprobación equivalente de CI aunque un hook debería haberlos detectado, o respuestas de encuestas sobre el uso de --no-verify, indicando el método. Si las mismas comprobaciones se ejecutan también en CI y si el hook se mantuvo sobre todo para dar respuesta rápida y no para imponer una regla. Si los hooks se instalan automáticamente (con un gestor de hooks o un script de arranque) o siguiendo instrucciones del README, ya que la fricción de la instalación puede explicar la mayor parte de la diferencia. La experiencia en un solo repositorio es bienvenida si se indica como tal; son más útiles las comparaciones entre varios repositorios con el mismo conjunto de hooks.