Git 3.0 setzt auf SHA-256 als Standard und verlangt Rust

Git 2.56-rc0 erschien am 11. September 2026, und das Release danach ist jenes, das Dinge bricht. Gits eigenes Dokument zu brechenden Änderungen listet auf, was Version 3.0 für neue Repositories ändert. Sie verwenden SHA-256 statt SHA-1, speichern Referenzen im reftable-Format und nennen den ersten Branch main. Der Bau von Git verlangt dann außerdem Rust. Phoronix berichtete über den Release-Kandidaten und verortet Git 3.0 etwa zum Jahresende 2026.

Jede dieser Voreinstellungen gilt nur für Repositories, die nach der Änderung angelegt werden. Bestehende Repositories arbeiten weiter wie bisher.

Die vier geänderten Voreinstellungen

Voreinstellung	Heute	In Git 3.0
Hash-Verfahren	SHA-1	SHA-256
Referenzspeicher	files	reftable
Name des ersten Branch	master	main
safe.bareRepository	all	explicit

Hinter der Hash-Änderung steht ein Sicherheitsargument. Gits Dokument nennt drei Angriffe auf SHA-1 beim Namen: SHAppening 2015, SHAttered 2017 und Shambles 2020. Eine Hash-Kollision in einer Versionsverwaltung bedeutet, dass zwei verschiedene Objekte dieselbe Identität beanspruchen können.

Reftable ersetzt das alte Layout, in dem jede Referenz eine Datei auf der Platte war. Gits Dokument nennt zwei Gründe: Es verhält sich korrekt auf Datei­systemen unter Windows und macOS, die Groß- und Kleinschreibung ignorieren, und es ist schneller bei Repositories mit vielen Referenzen.

Der Wechsel von safe.bareRepository von all auf explicit ist kleiner, hat aber einen echten Angriff im Rücken. Die heutige Voreinstellung lässt Git ein bare Repository irgendwo im Verzeichnisbaum finden, auch eines, das ein Angreifer in einem Arbeitsverzeichnis abgelegt hat.

Rust wird Pflicht

Die Rust-Pflicht kommt in Schritten. Gits Dokument beschreibt die Reihenfolge: Rust-Unterstützung wurde in Git 2.52 automatisch erkannt, in 2.55 standardmäßig aktiviert und wird in 3.0 verpflichtend.

Damit steht Git neben anderer Basissoftware, die denselben Schritt geht; Ubuntu ersetzt die GNU-coreutils durch Rust-Implementierungen in seiner nächsten Version. Wer Git auf einer ungewöhnlichen Plattform aus dem Quelltext baut, muss eine Rust-Toolchain künftig einplanen.

Git 3.0 entfernt außerdem seit Jahren veraltete Funktionen, darunter git pack-redundant, git whatchanged, die Unterstützung für Graft-Dateien und ältere Mechanismen zur Speicherung von Remotes.

Was 2.56 selbst bringt

Die Release Notes zu 2.56 drehen sich vor allem um Geschwindigkeit und Unterbau. Das Aufzählen loser Objekte während git status fällt von quadratischer auf O(n log n)-Komplexität. Die Berechnung der Merge-Basis bricht früher ab, wo sie kann, was die Notes als deutliche Beschleunigung beschreiben.

Es gibt eine neue Befehlsfläche: git refs erhält Unterbefehle zum Anlegen, Löschen, Aktualisieren und Umbenennen von Referenzen. Der Hinweistext von git status nennt nun Remote und Branch in dem git pull, das er vorschlägt, wenn Ihr Branch und sein Upstream auseinanderlaufen.

Phoronix hält fest, dass 2.56 zudem Diff-Muster für Swift ergänzt, die Attribute, Modifikatoren, fehlbare Initialisierer und Generics abdecken, und das ORT-Merge-Backend gegen beschädigte Bäume härtet. Darunter entfernt das Release weiter globale Variablen zugunsten von Zustand pro Repository, was die Grundlage für austauschbare Objektdatenbanken ist.

Was das für Entwickler bedeutet

Die Frage der Verträglichkeit lautet nicht, ob Ihr Git funktioniert, sondern ob Ihre Forge es tut. Ein SHA-256-Repository muss von allem verstanden werden, was es berührt, einschließlich Ihres Hosters, Ihrer CI-Runner und jedes Werkzeugs, das Objekt-IDs auswertet. Testen Sie diesen Pfad, bevor Sie ein Repository mit der neuen Voreinstellung anlegen.

Prüfen Sie den eigenen Code auf fest verdrahtete Annahmen zur Hash-Länge. Vierzig hexadezimale Zeichen stecken seit zwanzig Jahren in Skripten, regulären Ausdrücken und Datenbankspalten. SHA-256-Objektnamen sind vierundsechzig Zeichen lang, und ein varchar(40) schneidet sie schlicht ab.

Reftable lohnt sich früh, wenn Sie Repositories mit Tausenden Branches oder Tags pflegen, denn dort zahlt sich das Format aus. Der Branch-Name zählt am wenigsten: Die meisten Teams haben ihn vor Jahren gesetzt, und ein neu angelegtes Repository lässt sich mit einem Befehl umbenennen.