Git 2.54: Konfigurierbare Hooks und der neue Weg, Historie umzuschreiben

Die Open-Source-Versionsverwaltung Git ist in der Version 2.54 angekommen – und damit auch ein Paket an Neuerungen, das sich über die Releases 2.53 und 2.54 erstreckt. Mit über 137 Beitragenden, davon 66 Neueinsteiger, zeigt das Projekt einmal mehr die Vitalität der Open-Source-Community. Doch was steckt konkret in der neuen Version für Entwickler im Alltag? Einiges hat sich getan, insbesondere bei der Usability und der modernisierung der Interna.

Einfaches Umschreiben der Historie mit git history

Jeder, der schon einmal einen kleinen Tippfehler in einer Commit-Message drei Commits in der Vergangenheit korrigieren musste, kennt den Schmerz: Ein interaktiver Rebase (git rebase -i) ist für solche trivialen Aufgaben schlichtweg Overkill. Man muss eine Todo-Liste editieren, den richtigen Commit markieren und den Rebase-Prozess mühsam zu Ende führen.

Hier setzt der neue, experimentelle Befehl git history an. Er bietet mit den Subcommands reword und split genau die Werkzeuge für diese simplen Use-Cases. Mit git history reword <commit> lässt sich die Nachricht direkt ändern, git history split <commit> erlaubt es, einen Commit interaktiv (ähnlich wie bei git add -p) in zwei aufzuteilen. Git kümmert sich im Hintergrund um das Rewriting der nachfolgenden Branches.

Kritische Einordnung: Der Befehl ist ein Segen für den Alltag, hat aber bewusste Limitierungen. Er unterstützt keine Merge-Commits und bricht ab, wenn Konflikte entstehen. Es ist explizit als leichtgewichtiges Werkzeug gedacht, das unter der Haube auf dem neueren git replay aufbaut – nicht auf dem klassischen Rebase. Da das Feature noch als experimentell gilt, könnte sich die Syntax noch ändern. Dennoch ist es ein lang erwarteter Schritt hin zu einer nutzerfreundlicheren Historien-Pflege.

Konfigurationsbasierte Hooks: Das Ende der Skript-Symlink-Hölle

Git-Hooks waren lange Zeit ein organisatorischer Albtraum. Wer einen Pre-Commit-Hook (etwa einen Linter) projektweit oder gar unternehmensweit verteilen wollte, musste entweder Skripte manuell in jedes .git/hooks-Verzeichnis kopieren oder mit core.hooksPath und symlinks hantieren. Beides ist fehleranfällig und skaliert schlecht.

Git 2.54 führt endlich konfigurationsbasierte Hooks ein. Statt eines ausführbaren Skripts in einem versteckten Ordner kann der Hook nun deklarativ in der .gitconfig definiert werden:

[hook "linter"]
   event = pre-commit
   command = ~/bin/linter --cpp20

Der wahre Durchbruch ist jedoch die Unterstützung mehrerer Hooks für dasselbe Event. So können Linter und Secrets-Scanner unabhängig voneinander konfiguriert und in der definierten Reihenfolge ausgeführt werden. Mit hook.<name>.enabled = false lassen sich einzelne Hooks bei Bedarf temporär deaktivieren, ohne die Konfiguration löschen zu müssen. Mit git hook list behält man den Überblick. Das ist ein massiver Gewinn für die Developer Experience (DX) und macht externe Hook-Manager in vielen Fällen überflüssig.

Geometric Repacking als neuer Standard

Wer git maintenance nutzt, profitiert von einer leisen, aber wichtigen Änderung: Die Strategie geometric ist nun der Standard für maintenance.strategy (ersetzt das alte gc). Die geometrische Repacking-Strategie vermeidet die extrem ressourcenintensiven „Alles-in-einen-Pack“-Aktionen des klassischen Garbage Collectors. Stattdessen werden Objekte in einer geometrischen Folge von Packs organisiert. Das Resultat: Deutlich effizientere Repository-Wartung out-of-the-box, ohne dass Nutzer ihre Konfiguration anpassen müssen.

Unter der Haube: HTTP 429, MIDX und ODB-Refactoring

Neben den sichtbaren Features gab es auch wichtige Änderungen im Hintergrund:

• HTTP 429 Retry: Git kann nun mit HTTP 429 „Too Many Requests“ umgehen. Statt abzustürzen, honoriert Git den Retry-After-Header des Servers und versucht es erneut. Das ist ein riesiger Fortschritt für die Stabilität in Unternehmensnetzwerken oder bei CI/CD-Pipelines, die oft auf Rate-Limits stoßen.
• Incremental Multi-Pack Indexes (MIDX): Die MIDX-Maschinerie unterstützt nun Compaction. Kleinere MIDX-Layer werden zusammengeführt, was essenziell ist, um die Praxistauglichkeit für langlebige, große Repositories zu gewährleisten.
• Object Database (ODB) Refactoring: Die ODB-Interna wurden auf ein pluggable Backend-Design umgestellt. Davon profitiert vor allem der git backfill-Befehl für Partial Clones, der nun gezielt historische Blobs anfordern kann (z.B. nur für .c-Dateien oder einen bestimmten Commit-Range).

Qualitätsverbesserungen und Nützliches für den Alltag

Auch an den kleinen Dingen wurde gearbeitet:

• Abgelaufene GPG-Schlüssel: Ein Commit, der mit einem mittlerweile abgelaufenen GPG-Key signiert wurde, wird nicht mehr in alarmierendem Rot dargestellt. Git erkennt nun korrekt, dass die Signatur zum Zeitpunkt des Commits gültig war.
• Unicode-Aliase: Aliase unterstützen nun Unicode-Zeichen. Sogenannte Subsection-Syntax erlaubt nun auch Aliase wie hämta (Schwedisch für fetch) oder 状態 (Japanisch für status).
• git log -L kombiniert mit -S/-G: Die Zeilen-Log-Funktion (-L) lässt sich nun sinnvoll mit Pickaxe-Optionen (-S, -G) kombinieren, was das Tracing von Funktionsänderungen deutlich präziser macht.
• Triangular Workflows: git status kann nun über status.compareBranches konfiguriert werden, um den Push-Branch statt des Upstream-Branches als Referenz für „ahead/behind“ anzuzeigen.

Fazit: Git 2.54 (und 2.53) ist kein Release, das mit einer einzigen, alles überstrahlenden Funktion aufwartet. Vielmehr ist es ein unglaublich starkes Quality-of-Life-Update. Die Einführung konfigurationsbasierter Hooks und des git history-Befehls zeigen, dass das Projekt den Schmerzpunkt der täglichen Entwickler-Workflows ernst nimmt und Git von einem rein funktionalen Tool zu einem komfortablen Begleiter weiterentwickelt.

Quelle: GitHub Blog