Codequalität mit Git sichern

Codequalität mit Git sichern

0:00 Die meisten Teams prüfen ihren Code an genau einer Stelle: in der Pipeline, nachdem gepusht wurde. Das funktioniert — es dauert nur. Und wenn ein Agent im Minutentakt Code erzeugt, wird aus "es dauert" schnell "es bremst alles". In diesem Modul ziehen wir die Prüfungen dorthin, wo der Fehler entsteht: auf den eigenen Rechner, vor den Commit.

0:21 Dazu kommt ein zweites Thema, das oft übersehen wird, weil es nicht nach Qualität aussieht — die Commit-Nachricht. Auch sie ist ein Qualitätsmerkmal, und zwar eines, das erst dann auffällt, wenn es zu spät ist.

Qualität vor dem Push

0:34 Drei Kapitel liegen vor uns. Zuerst sortieren wir, an welchen Orten Prüfungen überhaupt stattfinden können und was jeder davon kostet. Dann kümmern wir uns um die Commit-Nachricht, mit einer verbreiteten Konvention und einer Vorlage im Repository. Und zum Schluss bauen wir den Pre-Commit-Hook — inklusive des Teils, an dem die meisten Teams scheitern: ihn allen zugänglich zu machen.

0:56 Denn ein Hook, den nur eine Person eingerichtet hat, prüft auch nur bei einer Person. Vier Ergebnisse am Ende dieses Moduls. Sie ordnen ein, wo Qualitätsprüfungen sinnvoll ansetzen — lokal, im Hook oder in der Pipeline, mit den jeweiligen Kosten. Sie strukturieren Commit-Nachrichten nach einer Konvention, die außerhalb Ihres Hauses genauso gelesen wird. Sie stellen eine Vorlage im Repository bereit und registrieren sie.

1:21 Und Sie schreiben einen Pre-Commit-Hook, versionieren ihn und rollen ihn im Team aus. Der letzte Teil ist der undankbarste und der wichtigste — er entscheidet, ob aus einer persönlichen Gewohnheit eine Teamregel wird.

Wo Qualität geprüft wird

1:35 Bevor wir irgendetwas einrichten, eine Sortierung. Es geht in diesem Kapitel nicht um Werkzeuge — Tests, Linter und Analysen haben Sie längst. Es geht um die Frage, an welchem Ort Sie diese Werkzeuge ausführen. Qualität hat in einem Repository zwei Seiten, und über die zweite spricht kaum jemand. Die erste ist der Code selbst: Fehler, Sicherheitslücken, Testabdeckung — das übliche Programm. Die zweite sind die Metadaten von Git, allen voran die Commit-Nachricht.

2:04 Der Unterschied liegt darin, wann es auffällt. Schlechter Code fällt im Review auf, spätestens beim ersten Ausfall. Eine schlechte Commit-Nachricht fällt nie auf — bis zu dem Tag, an dem jemand die Historie durchsucht und nichts findet. Dann ist sie nicht mehr zu reparieren. Dieselben Werkzeuge, drei Orte, drei völlig unterschiedliche Eigenschaften.

2:26 Lokal von Hand ist am schnellsten und am unzuverlässigsten — es hängt daran, dass jemand daran denkt, und es gibt keinen Nachweis, dass es passiert ist. Die Pipeline ist das Gegenteil: langsam, aber belegbar für alle. Der Hook liegt dazwischen und übernimmt von beiden das Bessere — er läuft zuverlässig, weil Git ihn startet, und er läuft lokal, also schnell. Was er nicht kann, ist beweisen.

2:49 Er ist umgehbar, und das sollte man wissen, bevor man ihn zur einzigen Instanz erklärt. Vier Gründe, und sie summieren sich. Die Pipeline startet erst nach dem Push — der fehlerhafte Stand ist zu diesem Zeitpunkt bereits außerhalb Ihres Rechners. Auschecken und Installieren kosten jedes Mal Zeit, die lokal längst investiert wäre. Bei vollem Team wartet Ihr Lauf hinter fremden Läufen.

3:13 Und der teuerste Punkt steht am Schluss: Der Weg vom Fehlschlag zurück zur Korrektur ist lang. Sie sind inzwischen bei etwas anderem, müssen zurückwechseln, den Kontext neu aufbauen. Bei einem einzelnen Fehler ist das ärgerlich. Bei zwanzig am Tag ist es der halbe Tag. Fünf Schritte, und der letzte ist der entscheidende. Wir stellen eine Commit-Vorlage bereit und registrieren sie. Wir schreiben einen Hook und versionieren das Hook-Verzeichnis.

3:40 Und dann automatisieren wir die Einrichtung. Warum das nötig ist, steht in der Fußzeile: Sowohl die Vorlage als auch der Hook sind lokale Einstellungen. Git kennt keinen Mechanismus, der sie beim Klonen mitbringt. Wenn Sie also nur die ersten vier Schritte gehen, haben Sie am Ende eine sehr gut konfigurierte Arbeitsumgebung — Ihre eigene. Alle anderen arbeiten weiter wie bisher.

4:03 Eine Bestandsaufnahme, die schnell geht und oft überrascht. Notieren Sie für Tests, Linting und Formatierung jeweils, wo sie heute laufen — und wie viel Zeit zwischen Fehler und Rückmeldung vergeht. Diese zweite Zahl ist die interessante. Bei vielen Teams liegt sie zwischen acht und zwanzig Minuten, und niemand hat sie je gemessen.

4:22 Der Hinweis gibt gleich die wichtigste Faustregel mit: Alles, was länger als eine Minute braucht, gehört nicht in den Hook. Ein Hook, der die Arbeit spürbar aufhält, wird umgangen — und zwar zu Recht. Vier Fehler auf dieser Ebene. Prüfungen doppelt pflegen, im Hook und in der Pipeline mit unterschiedlichem Stand — dann streiten sich beide, und niemand weiß, welcher recht hat.

4:45 Den Hook so lang machen, dass er umgangen wird; es gibt ein Flag dafür, und es wird benutzt. Die Pipeline abschaffen, weil der Hook ja jetzt prüft — damit verlieren Sie den Nachweis, und der ist der eigentliche Zweck der Pipeline. Und der vierte: Commit-Nachrichten als Formalie behandeln. Sie sind Metadaten, und Metadaten sind das, wonach man später sucht.

Commit-Vorlagen und Conventional Commits

5:07 Wir haben alle schon Commit-Nachrichten geschrieben, die niemandem helfen. "Fix", "Anpassung", "läuft jetzt". In diesem Kapitel geht es um eine Form, die das verhindert — und um den Weg, sie in Ihr Repository zu bringen. Conventional Commits ist eine verbreitete Konvention für Commit-Nachrichten. Sie schreibt keine Werkzeuge vor, sondern eine Form — vergleichbar mit dem Aufbau einer Geschäftsadresse: Name, Straße, Postleitzahl, Ort.

5:35 Niemand denkt darüber nach, und genau deshalb funktioniert es weltweit. Hier sind es fünf Bestandteile: Art der Änderung, optionaler Geltungsbereich, kurze Beschreibung, optionaler Rumpf, optionale Fußzeilen. Der eigentliche Gewinn ist nicht die Schönheit. Es ist die Maschinenlesbarkeit — Werkzeuge können aus solchen Nachrichten Änderungslisten erzeugen und Versionssprünge ableiten.

5:59 Fünf Teile, aber nur drei davon sieht man im Alltag ständig: Typ, Geltungsbereich und Beschreibung. Sie bilden zusammen die erste Zeile — und das ist die Zeile, die in jeder Übersicht auftaucht, im Log, in der Liste der Pull Requests, in Änderungsprotokollen. Deshalb die Beschränkung auf rund fünfzig Zeichen: Sie soll überall ungekürzt lesbar bleiben. Rumpf und Fußzeile sind optional und ohne Längenbegrenzung.

6:24 Meine Empfehlung: Nutzen Sie den Rumpf für das Warum. Die erste Zeile sagt, was passiert ist — der Rumpf sagt, warum es passieren musste. Drei Nachrichten, die zeigen, wie unterschiedlich detailliert dieselbe Konvention sein darf. Die erste ist minimal und völlig ausreichend für ein kleines Feature. Die zweite ergänzt einen Geltungsbereich — hilfreich, sobald ein Repository mehrere Teile enthält. Die dritte zeigt alle drei Ebenen: Kopfzeile, Rumpf, Fußzeile.

6:53 Worauf es hier ankommt, ist die Leerzeile vor der Fußzeile. Sie ist keine Kosmetik — die Konvention verlangt sie, und Werkzeuge, die solche Nachrichten auswerten, erkennen die Fußzeile nur daran. Ein Breaking Change, der direkt unter der Betreffzeile klebt, ist für sie unsichtbar. Fünf Schritte, und das Wort Vorlage ist dabei fast zu großspurig. Was Sie schreiben, ist eine Textdatei mit Kommentarzeilen: der Aufbau, die erlaubten Typen, zwei Beispiele.

7:21 Diese Datei committen Sie, damit alle dieselbe Fassung haben. Dann registrieren Sie sie lokal — und genau da liegt der Haken, der schon angesprochen wurde: Dieser vierte Schritt ist eine persönliche Einstellung. Jede Person im Team muss ihn selbst ausführen. Die Datei ist geteilt, ihre Nutzung nicht. Merken Sie sich das für den Schluss dieses Moduls; dort lösen wir es.

7:44 Zwei Zeilen, mehr ist es nicht. Beim nächsten Commit öffnet sich der Editor und zeigt statt einer leeren Fläche Ihre Struktur mit Erklärungen. Der Effekt ist größer, als man erwartet — auch bei Agenten übrigens, denn viele erzeugen ihre Nachricht in genau diesem Editor und richten sich nach dem, was sie dort vorfinden. Ein Detail noch: Zeilen mit einer Raute landen nicht in der fertigen Nachricht. Sie dürfen also ausführlich erklären, ohne dass die Historie davon zugemüllt wird.

8:12 Schreiben Sie eine Vorlage für Ihr eigenes Projekt — so, dass sie ohne Rückfragen verstanden wird. Der Adressat ist dabei doppelt: der neue Kollege und der Agent, der sie im Editor vorfindet. Beide lesen sie zum ersten Mal, beide haben keine Gelegenheit nachzufragen. Der Hinweis fasst die wirksamste Technik zusammen: Zwei konkrete Beispiele aus Ihrem eigenen Projekt wirken mehr als jede Erklärung.

8:36 Menschen wie Modelle orientieren sich lieber an einem Muster als an einer Regel. Vier Punkte. Die Vorlage nur lokal ablegen — dann hat sie genau eine Nutzerin. Von der Vorlage erwarten, dass sie die Form erzwingt; das tut sie nicht, sie schlägt vor. Wer Verbindlichkeit braucht, prüft zusätzlich in der Pipeline oder im Hook.

8:57 Typen erfinden, die außerhalb Ihres Teams niemand kennt — dann verlieren Sie genau den Vorteil, den eine verbreitete Konvention hat. Und der letzte: die Beschreibung mit Dateinamen füllen. Welche Dateien betroffen sind, steht im Diff. Was fehlt, ist die Absicht.

Pre-Commit-Hooks

9:14 Kommen wir zum Werkzeug, das die Prüfung nach vorn zieht. Git kann an bestimmten Punkten eigene Programme starten — das ist keine Erweiterung, das ist eingebaut. Wir sehen uns an, wie das funktioniert und warum die Sache am Ende trotzdem an einer Kleinigkeit hängt. Die Git-Dokumentation ist an dieser Stelle erfreulich schlicht: Hooks sind Programme, die Git an bestimmten Punkten seiner Ausführung startet.

9:39 Clientseitige Hooks laufen auf Ihrem Rechner, rund um Commit und Merge. Serverseitige laufen beim Empfang von Pushes. Der Mechanismus dahinter ist so alt wie einfach: Endet das Programm mit einem Status ungleich null, bricht Git die Aktion ab. Kein Plugin-System, keine Schnittstelle, keine Konfigurationssprache — ein ausführbares Programm und ein Rückgabewert.

10:00 Genau deshalb funktioniert es mit jeder Programmiersprache, die Sie mögen. Der Ablauf in fünf Schritten, und er ist bewusst unspektakulär. Sie stagen Ihre Änderungen und rufen den Commit auf. An diesem Punkt übernimmt Git und startet den Hook. Der führt aus, was Sie hineingeschrieben haben — Tests, Stilprüfung, was immer.

10:20 Läuft alles durch, entsteht der Commit, und Sie merken vom Hook nichts außer ein paar Sekunden Wartezeit. Schlägt etwas fehl, gibt es keinen Commit, und Sie sehen die Ausgabe des Skripts. Das ist der ganze Zauber: Der Rückgabewert entscheidet, sonst nichts. Drei Zeilen für einen vollwertigen Hook. Worauf es ankommt, ist die Verkettung in der zweiten Zeile — schlagen die Tests fehl, endet das Skript sofort mit einem Fehlerstatus, und Git bricht ab.

10:48 Sonst läuft noch die Stilprüfung. Und dann kommt der Punkt, über den wirklich jeder einmal stolpert und der in der Fußzeile steht: Die Datei muss ausführbar sein. Ist sie es nicht, startet Git sie stillschweigend nicht. Keine Fehlermeldung, keine Warnung — der Commit läuft einfach durch, und Sie glauben tagelang, Sie wären abgesichert.

11:08 Hier kommt die Kleinigkeit, die alles entscheidet. Der Ordner mit den Git-Interna wird nicht versioniert — das ist gewollt, dort liegen ja lokale Daten. Ein Hook, den Sie dort ablegen, bleibt damit auf genau einem Rechner. Neue Teammitglieder starten ohne jede Prüfung und merken nichts davon. Änderungen am Hook erreichen niemanden und lassen sich nicht nachvollziehen. Und die mitgelieferten Beispieldateien tragen alle die Endung sample, laufen also ebenfalls nicht.

11:36 Die Lösung ist einfach, aber sie muss einem jemand sagen: Der Hook zieht um. Fünf Zeilen, die das Problem lösen. Sie legen ein eigenes Verzeichnis an, verschieben den Hook dorthin, machen ihn ausführbar und sagen Git, wo es künftig suchen soll. Danach liegt der Hook im Repository, ist versioniert, wird beim Review gelesen und verändert sich für alle gemeinsam.

11:57 Ein Punkt bleibt: Die Konfigurationszeile, die auf das neue Verzeichnis zeigt, ist wieder eine lokale Einstellung — dasselbe Muster wie bei der Vorlage. Der Hook ist geteilt, seine Aktivierung nicht. Und damit sind wir bei der letzten Frage dieses Moduls. Drei Wege, und sie unterscheiden sich vor allem in ihrer Verlässlichkeit.

12:17 Eine Anleitung im README trägt in kleinen Teams mit seltenen Zugängen — sie hat den Vorteil, dass sie nichts kostet, und den Nachteil, dass sie gelesen werden muss. Ein Werkzeug der jeweiligen Sprache übernimmt die Einrichtung automatisch, sofern es eines gibt. Und der dritte Weg klinkt sich in die ohnehin vorhandene Projekteinrichtung ein.

12:37 Welchen Sie wählen, ist zweitrangig. Entscheidend ist die Fußzeile: Ohne einen dieser Wege prüft am Ende nur, wer den Befehl zufällig kannte. Nehmen Sie eine Prüfung, die bisher erst in der Pipeline lief, und verankern Sie sie lokal — so, dass sie ohne Zutun der Entwickler ausgeführt wird. Und dann testen Sie sie richtig: Der Hinweis sagt, brechen Sie bewusst einen Test. Warten Sie nicht darauf, dass zufällig etwas fehlschlägt.

13:02 Erfolgreich ist die Übung, wenn der Commit mit der Ausgabe des Skripts abbricht und nach der Korrektur durchläuft. Diese beiden Beobachtungen zusammen beweisen, dass der Hook tatsächlich greift — eine von beiden allein beweist gar nichts. Vier zum Schluss. Den Hook nicht ausführbar machen — schon erwähnt, aber es ist wirklich der häufigste Fehler überhaupt.

13:23 Vollständige Integrationstests hineinlegen und damit alle ausbremsen; der Hook ist für Sekunden gedacht, nicht für Minuten. Das Hook-Verzeichnis konfigurieren, aber die Einrichtung nicht automatisieren — dann sind Sie wieder bei einer Person. Und der wichtigste zum Mitnehmen: Ein Hook ist keine Sicherheitsmaßnahme. Es gibt ein Flag, das ihn überspringt, und das ist kein Fehler im Design.

13:47 Verbindlichkeit gibt es nur auf dem Server.

Modul 4 geschafft

13:50 Halten wir fest: Der Pre-Commit-Hook prüft dort, wo der Fehler entsteht — schnell, zuverlässig und mit denselben Werkzeugen, die auch die Pipeline verwendet. Conventional Commits geben der Historie eine Form, die auch außerhalb Ihres Hauses gelesen wird. Und beides, Vorlage wie Hook, gehört ins Repository und nicht auf einen einzelnen Rechner. Damit ist die lokale Seite weitgehend abgedeckt.

14:13 Im nächsten Modul kommt eine neue Anforderung dazu, die viele Organisationen gerade formulieren: Governance. Und die verlangt nicht nur gute Arbeit, sondern den Nachweis darüber.