Letztes Jahr, Beratungsmandat bei einem Maschinenbauer mit knapp 60 Mitarbeitenden. Das Entwicklungsteam: acht Leute, davon vier mit echter Softwareausbildung, zwei Quereinsteiger aus dem Automatisierungsbereich, ein Werksstudent und ein Entwickler kurz vor der Rente, der noch auf CVS schwört. Die Einführung von Git-Feature-Branches war dort gerade drei Monate alt. Mein erster Tag vor Ort: Ich schaue ins Repository, sehe 94 offene Branches, von denen 61 älter als vier Wochen sind, und lese Commit-Nachrichten wie asdf, jetzt aber, fix2_final_FINAL und mein persönlicher Favorit: test (bitte nicht mergen) — der Branch war acht Monate alt.
Das ist kein Einzelfall. Das ist der Normalzustand in deutschen KMU. Und genau deswegen lese ich neue Git-Feature-Posts wie den von Andrew Lock mit zwei Brillen gleichzeitig: einmal als jemand, der die technische Eleganz zu schätzen weiß — und einmal als jemand, der weiß, wie es in der echten Welt aussieht, wenn man diese Features ausrollen will.
Was Andrew Lock sagt
Andrew Lock hat einen soliden, handwerklich guten Post zu Git 2.54 geschrieben. Im Mittelpunkt stehen zwei neue Unterbefehle unter dem neuen git history-Command: Mit git history reword kannst du die Commit-Nachricht eines beliebigen Commits ändern, ohne vorher den Branch auschecken zu müssen — ein einziger Befehl ersetzt den bisher nötigen Checkout-plus-interaktiver-Rebase-Workflow. Mit git history split kannst du einen zu großen Commit nachträglich in zwei aufteilen, ebenfalls ohne Checkout, direkt über einen interaktiven Hunk-Selektor. Außerdem deckt der Post ab, dass Git 2.54 Hooks jetzt in Config-Dateien definiert werden können — was bedeutet, dass du Team-Hooks ins Repository packen und per git config aktivieren kannst — sowie neue Statistik-Befehle. Lock kommt aus der .NET-Welt, arbeitet viel mit Rider und stacked branches, und seine Perspektive ist klar die eines Entwicklers, der Git bereits auf hohem Niveau beherrscht und nach Workflow-Optimierungen sucht.
Wie das im KMU wirklich landet
Fangen wir mit der ehrlichen Einschätzung an.
git history reword und git history split: Technisch elegant. Tatsächlich nützlich — aber für wen? Diese Features setzen voraus, dass im Team bereits eine Kultur der sauberen Commit-Hygiene existiert. Dass Leute Commit-Nachrichten bewusst formulieren, Commits atomar halten und sich überhaupt Gedanken machen, ob ein Commit zu groß ist. In Teams, die das schon tun, und es gibt sie auch im Mittelstand, ist git history reword ohne Checkout wirklich eine Erleichterung. Ich schätze, das betrifft vielleicht 20–25 % der Entwicklungsteams in KMU, mit denen ich arbeite. Für die anderen 75–80 %, wo git commit -m "fix" der Standard ist, wird dieses Feature schlicht nicht benutzt werden. Nicht weil die Leute böswillig sind, sondern weil das Problem, das es löst, für sie noch nicht existiert. Sie sind noch nicht an dem Punkt, wo Commit-Hygiene auf ihrer Prioritätsliste steht.
Die fehlende Mittelstands-Perspektive in Locks Post: Er schreibt für Leute, die interaktives Rebase bereits kennen und nur die Reibung reduzieren wollen. Für Teams, die Rebase überhaupt nicht kennen oder fürchten, ändert git history reword nichts am eigentlichen Problem — dem fehlenden Verständnis, warum saubere History überhaupt wichtig ist. Das ist eine Schulungs- und Kulturfrage, kein Tooling-Problem.
Hooks in Config-Dateien: Das ist das Feature, das mich in diesem Release wirklich interessiert. Und bezeichnenderweise ist es in Locks Post eher eine Randnotiz, weil es aus seiner Perspektive weniger spektakulär ist als die neuen History-Commands.
Für KMU ist es das Gegenteil. Das klassische Problem mit Git Hooks: Sie liegen im .git/hooks-Verzeichnis, das nicht versioniert wird. Jeder Entwickler muss sie manuell einrichten. In der Praxis bedeutet das, dass kein Mensch sie einrichtet — außer dem einen Senior, der es ohnehin schon weiß. Ergebnis: kein konsistentes Pre-Commit-Linting, keine automatischen Checks, keine erzwungenen Standards.
Wenn Hooks jetzt in Config-Dateien definiert und ins Repository eingecheckt werden können, ändert das die Dynamik grundlegend: Du kannst als Team sicherstellen, dass jeder Entwickler, der das Repository klont und git config korrekt gesetzt hat, dieselben Hooks aktiv hat. Kombiniert mit einer README-Sektion oder einem Onboarding-Script ist das der realistischste Weg, Git-Standards in einem heterogenen KMU-Team tatsächlich durchzusetzen — ohne auf jeden Entwickler angewiesen zu sein, der das manuell konfiguriert.
Repository-Statistiken: Nice to have. In meiner Beratungspraxis habe ich noch keinen KMU-Kunden gehabt, bei dem Repo-Statistiken ein Problem gelöst hätten, das vorher ungelöst war. Das ist eher etwas für Engineering-Manager in größeren Organisationen, die Aktivitätsmetriken brauchen.
Meine konkrete Empfehlung
Wenn du heute Git 2.54 aktualisierst und dein Team aus 8–50 Entwicklern besteht, dann ist das eine sinnvolle Reihenfolge:
Sofort: Schau dir die neuen Config-basierten Hooks an. Wenn ihr noch keine konsistenten Pre-Commit-Checks habt — Linting, Formatierung, keine Secrets im Commit — ist jetzt der richtige Moment, das sauber einzurichten. Einmal gemacht, versioniert, fertig. Das ist keine aufwändige Initiative, das ist ein Nachmittag Arbeit mit langfristiger Wirkung.
Mittelfristig: git history reword und git history split lohnen sich als Thema in eurem nächsten Team-Workshop, wenn ihr ohnehin an Git-Workflows arbeitet. Zeig diese Features denjenigen, die schon mit interaktivem Rebase arbeiten. Für alle anderen ist es verfrüht.
Nicht machen: Diese Features als Einstieg in Git-Fortbildung nutzen. Wer noch nicht versteht, warum Commit-Hygiene wichtig ist, braucht zuerst das Konzept, nicht das Tool.
Lock schreibt das nicht falsch — er schreibt es für seine Zielgruppe. Aber seine Zielgruppe ist nicht die Entwicklungsabteilung eines Maschinenbauers mit 60 Mitarbeitenden, die gerade Feature-Branches eingeführt hat.
Der vollständige Original-Beitrag von Andrew Lock: New features in Git 2.54: easier rebasing, hooks, and statistics
Wenn du magst, besprich ich das mit dir direkt — was in eurem Team realistisch ist, welche Git-Baustelle zuerst dran ist, und ob ein Nachmittag Workshop oder ein paar Stunden Konfiguration mehr bringt.
— Bernhard