Git 3.0 setzt auf SHA-256 als Standard und verlangt Rust
Git 2.56-rc0 erschien am 11. September 2026, und das dahinter liegende Release 3.0 stellt neue Repositories auf SHA-256, reftable und den Branch main um.
Von Claire Whitmore
3 Min. Lesezeit
Maschinell übersetzt aus dem englischen Original, das Claire Whitmore auf Fakten geprüft und redigiert hat. Es gilt die englische Fassung. So arbeiten wir

Die Zahlen
- SHA-1 collision attacks the hash change cites: 2015, 2017 and 2020
- 3
- release candidate published on September 11, 2026
- 2.56
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 Hash-Umstellung hat inzwischen öffentlichen Widerspruch ausgelöst: Scott Chacon hält den SHA-256-Standard für einen teuren Fehler, und Gits eigenes Dokument nennt kein Veröffentlichungsdatum.
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 Dateisystemen 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.
Fortsetzung: Git 2.56 bringt history drop und delete-merged.
Quellen
- Git 2.56-rc0 Released With Updated Contribution Guidelines, Improvements For Swift - Phoronix
- Git 2.56 release notes - Git project
- Git BreakingChanges documentation - Git project
Ähnliche Artikel

Ubuntu 26.10 stellt cp, mv und rm auf Rust-Coreutils um
Ubuntu 26.10 übergibt cp, mv und rm an Rust. Ein Audit mit 113 Befunden hielt die drei aus 26.04 LTS heraus, stabil erscheint am 15. Oktober.

Rust warnt Maintainer vor gefälschten Job-Videocalls
Rusts Sicherheitsteam meldet: Angreifer vereinbaren unter falschen Jobangeboten Videocalls mit Crate-Ownern und bitten dann um die Installation eines fehlenden Codecs.

Rustls 0.23.45 behebt einen TLS-1.3-Fehler von 2024
Die Versionen 0.23.13 bis 0.23.44 akzeptierten TLS-1.3-Handshake-Nachrichten auf der falschen Verschlüsselungsebene, ein Fehler aus dem September 2024.