Die Relevanz von Git-Hooks

Relevanz von schnellem Feedback

Verallgemeinert gesprochen, spielt Feedback an sich eine entscheidende Rolle im Lernprozess. Die Geschwindigkeit ist eine Form der Effizienzsteigerung. Im Laufe meiner Karriere habe ich wiederholt erlebt, dass ich als ungeduldiger Entwickler auf dieses Thema besonders achten muss.

Wenn also zwischen meiner Aktion und dem Feedback nicht nur ein Medienbruch stattfindet, sondern zusätzlich viele Minuten vergehen, ist Frustration sicher und die Effizienz gering. Schlimmer als langwierige Git-Hooks sind gar keine Git-Hooks. Ich gehe den gesunden Mittelweg. Aus Erfahrung zeigt sich, was hilft. Doch zuerst betrachte ich, wie mir Git-Hooks helfen.

Git-Hooks als Qualitätssicherung

Ich möchte in diesem Artikel mein Augenmerk auf den pre-push-Git-Hook richten. Dieser Git-Hook erlaubt es mir, bevor ich Code ins Repository schiebe, Aktionen durchzuführen. Hierbei eignet es sich, jede qualitätsfördernde Maßnahme vorab auszuführen, die auf dem Build-Server zu einem Fehler führt. Das direkte Feedback ermöglicht mir, während ich gedanklich noch im Kontext bin, den Fehler schneller zu beheben, als es im Falle einer Mail aus dem Buildsystem 15 Minuten später der Fall wäre.

Allerdings sollte ich nicht alle Build-Schritte lokal ausführen, da das insgesamt zu lange dauert. Deswegen machen wir den Build auf einem separaten System. Wenn zwischen einer Aktion – dem Befehl git push – und dem Feedback mehr als eine Minute vergeht, muss ich mich disziplinieren, auf das Ende des Befehls zu warten und nicht reflexartig in den Messenger oder die Mail zu schauen. Finde ich dort neue Inhalte in Form von Nachrichten, widme ich mich diesen. Die Ablenkung ist perfekt. Vielleicht 10 Minuten später stelle ich frustriert fest, dass mein Code den Rechner nicht verlassen hat.

Je nachdem, wie tolerant und geduldig du und dein Team sind, können die im Git-Hook ausgeführten Maßnahmen in Umfang und Länge variieren. Ich lege dir aus meinen Erfahrungen den Richtwert von maximal einer Minute ans Herz. Zur Verdeutlichung: Es stellt sich nicht die Frage, ob du diesen Git-Hook nutzen solltest. Der ist obligatorisch!

Was tun im Git-Hook?

Die obige Feststellung gilt für alle Projekte, deren Code mit einer Versionsverwaltung verwaltet wird. Unabhängig von der Programmiersprache oder der Fachdomäne. Für die unten von mir genannten Schritte, die bei dem Pre-Push-Git-Hook ausgeführt werden, gilt das genauso:

• Rechtschreibung prüfen: Je nach Repositorygröße erfolgt die Prüfung in weniger als einer Sekunde.
• TypeScript kompilieren: Prüft die Typdefinitionen innerhalb weniger Sekunden.
• Einhaltung der Linting-Regeln: Sichert die Einhaltung der Codeformatierung innerhalb weniger Sekunden.
• Security-Auditing: Prüft, ob die verwendeten NPM-Pakete bekannte Sicherheitslücken aufweisen.
• Unit-Tests: Der potenziell langwierigste und kontroverseste Punkt in der Liste, weil mit der Repositorygröße und mieser Testqualität die Dauer schnell anwachsen kann.

Sollte bei dir im Team der Schritt in Erwägung gezogen werden, die Unit-Tests wegen der Dauer aus dem Pre-Push-Git-Hook zu entfernen, oder das Abschweifen beim Ausführen des Befehls im Team überhandnehmen, ist das ein dringliches Warnsignal: Die Tests und deren Qualität haben gelitten. Die dort aufgebauten technischen Schulden müssen im Team Priorität haben. Statt den Testzeitpunkt zu verschieben, gilt es, die Testperformanz zu verbessern. Sonst werden in absehbarer Zeit immer weniger Tests verfasst. Das schränkt die Möglichkeiten, sicher und schnell zu liefern, ein!

npm run cspell:lint → "cspell:lint": "cspell \"**/*.ts\""
npm run ts → "ts": "tsc --noEmit"
npm run lint → "lint": "eslint src/** --no-ignore --cache --cache-location=node_modules/.cache/eslint"
npm run audit → "audit": "better-npm-audit audit"
npm run test → "test": "vitest run"

Meine via Husky eingebundene Befehlskette in einem Node.js-Projekt mit den referenzierten Skripts aus der package.json

Was ich nicht im Git-Hook ausführe

Ich sehe davon ab, die Testabdeckung als Kennzahl in Prozent aufzunehmen. Sobald der Wert unter eine willkürliche Grenze fällt, passiert meist eines der beiden Dinge: Die Grenze wird gesenkt oder es wird krampfhaft versucht, ein paar Tests an beliebiger Stelle zu schreiben, die den Wert auf das Minimum erhöhen. Beides erhöht nicht die Test- oder Codequalität. Eine ausgeprägte Codereview-Mentalität oder testgetriebene Entwicklungsansätze sind hierfür zielführender.