Quais hooks de pre-commit duram um ano em um repositório de equipe, e quais são removidos ou rotineiramente ignorados?

Pergunta em aberto

A documentação de githooks afirma que o hook pre-commit é invocado por git commit, pode ser ignorado com --no-verify e que uma saída diferente de zero aborta o commit. Isso faz do hook local uma convenção, e não um controle: ele funciona apenas enquanto os contribuidores o mantêm instalado e não o pulam. As equipes adicionam hooks com entusiasmo (formatador, linter, scanner de segredos, verificador de tipos, um subconjunto rápido de testes, verificações da mensagem de commit), mas a wiki não tem nenhum registro do que acontece com esses hooks ao longo do tempo. Quais deles continuam em vigor um ano depois? Quais foram apagados, tornados opcionais ou movidos para uma verificação de CI porque eram lentos demais, geravam falsos positivos ou quebravam na máquina de alguém? Com que frequência --no-verify é usado, e por quem: por novos contribuidores que nunca instalaram o gerenciador de hooks, ou por pessoas experientes que pulam uma verificação lenta? A resposta é diferente entre hooks que corrigem em silêncio (um formatador que reescreve o arquivo) e hooks que apenas recusam (um linter que falha)? E os agentes que fazem commits no repositório chegam a executar os hooks?

A pergunta importa porque um hook ignorado em metade das vezes pode ser pior do que nenhum: ele dá à equipe a impressão de que uma classe de problema está tratada, enquanto o CI ainda precisa detectá-la, e a divergência só é percebida quando a verificação de CI também está ausente.

O que uma resposta útil contém

Idade do repositório, tamanho da equipe e se os contribuidores são internos, externos ou agentes automatizados. A lista de hooks no momento em que foram introduzidos e um ano depois, com o motivo de cada remoção ou mudança (tempo de execução, falsos positivos, quebra em alguma plataforma, substituição pelo CI, substituição por integração com o editor). A distribuição do tempo de execução dos hooks, já que o tempo de execução é o motivo mais citado para ignorá-los. Evidências de que os hooks são ignorados: contagens de commits que falham na verificação equivalente do CI embora um hook devesse tê-los detectado, ou respostas de pesquisa sobre o uso de --no-verify, com o método indicado. Se as mesmas verificações também rodam no CI, e se o hook foi mantido principalmente para dar feedback rápido, e não para impor a regra. Se os hooks são instalados automaticamente (um gerenciador de hooks, um script de bootstrap) ou por instrução no README, já que o atrito da instalação pode explicar a maior parte da diferença. Experiências de um único repositório são bem-vindas se forem identificadas como tal; comparações entre vários repositórios com o mesmo conjunto de hooks são mais úteis.