Welche Pre-Commit-Hooks überleben ein Jahr in einem Team-Repository, und welche werden entfernt oder regelmässig umgangen?

Offene Frage

Die Githooks-Dokumentation hält fest, dass der Hook pre-commit von git commit aufgerufen wird, sich mit --no-verify umgehen lässt und dass ein Exit-Code ungleich null den Commit abbricht. Das macht einen lokalen Hook zu einer Konvention statt zu einer Kontrolle: Er wirkt nur, solange Mitwirkende ihn installiert halten und ihn nicht überspringen. Teams fügen Hooks mit Begeisterung hinzu (Formatierer, Linter, Secret-Scanner, Type-Checker, eine schnelle Teilmenge von Tests, Commit-Message-Prüfungen), aber das Wiki hat keine Aufzeichnung darüber, was mit diesen Hooks über die Zeit geschieht. Welche von ihnen sind ein Jahr später noch vorhanden? Welche wurden gelöscht, optional gemacht oder in eine CI-Prüfung verschoben, weil sie zu langsam waren, falsch positive Ergebnisse lieferten oder auf jemandes Maschine nicht liefen? Wie oft wird --no-verify verwendet, und von wem: von neuen Mitwirkenden, die den Hook-Manager nie installiert haben, oder von erfahrenen, die eine langsame Prüfung überspringen? Unterscheidet sich die Antwort zwischen Hooks, die Dinge still korrigieren (ein Formatierer, der die Datei umschreibt), und Hooks, die nur ablehnen (ein Linter, der fehlschlägt)? Und führen Agenten, die in das Repository committen, die Hooks überhaupt aus?

Die Frage ist wichtig, weil ein Hook, der zur Hälfte der Zeit umgangen wird, schlimmer sein kann als gar keiner: Er vermittelt dem Team den Eindruck, eine Problemklasse sei abgedeckt, während die CI sie trotzdem noch abfangen muss, und die Diskrepanz fällt erst auf, wenn auch die CI-Prüfung fehlt.

Was eine nützliche Antwort enthält

Repository-Alter, Teamgrösse und ob Mitwirkende intern, extern oder automatisierte Agenten sind. Die Liste der Hooks bei Einführung und ein Jahr später, mit dem Grund für jede Entfernung oder Änderung (Laufzeit, falsch positive Ergebnisse, Plattformdefekte, durch CI ersetzt, durch Editor-Integration ersetzt). Die Verteilung der Hook-Laufzeiten, da Laufzeit der übliche genannte Grund für das Umgehen ist. Belege zum Umgehen: Anzahl der Commits, die die entsprechende CI-Prüfung nicht bestehen, obwohl ein Hook sie hätte abfangen sollen, oder Umfrageantworten zur Verwendung von --no-verify, mit angegebener Methode. Ob dieselben Prüfungen auch in der CI laufen und ob der Hook hauptsächlich für schnelles Feedback statt für Durchsetzung beibehalten wurde. Ob Hooks automatisch installiert werden (ein Hook-Manager, ein Bootstrap-Skript) oder per Anleitung im README, da die Installationsreibung einen Grossteil des Unterschieds erklären könnte. Erfahrung aus einem einzelnen Repository ist willkommen, sofern so gekennzeichnet; Vergleiche über mehrere Repositorys mit demselben Hook-Satz sind nützlicher.