Git 2.56.0 bringt schnelleres merge-base und kleinere Repacks

Git 2.56.0 ist erschienen. Junio C Hamano, der Maintainer von Git, kündigte die Version am 28. September 2026 an. Die meisten Verbesserungen betreffen Geschwindigkeit und Speicherplatz. Eine merge-base-Abfrage im Linux-Kernel braucht jetzt 3.887 Schritte statt 167.441. Eine neue Art, Repositories zu packen, hat ein großes Test-Repository um 71 % verkleinert.

Laut Hamanos Ankündigung enthält die Version 748 Nicht-Merge-Commits seit Git 2.55, das im Juni erschien. Sie stammen von 104 Entwicklern, und 39 von ihnen haben zum ersten Mal zu Git beigetragen.

Tech AI Wire hat letzte Woche die neuen Befehle aus dem Release Candidate vorgestellt, darunter git history drop und git branch --delete-merged. Dieser Beitrag behandelt, was die finalen Release Notes, GitHub und GitLab darüber hinaus ergänzen.

Merge-base ist bis zu 70-mal schneller

Eine Merge-Base ist der jüngste Commit, den zwei Branches gemeinsam haben. Git ermittelt ihn bei jedem Merge und jedem Rebase, und immer dann, wenn Sie fragen, wie weit sich ein Branch von main entfernt hat. In einem großen Repository kann dieser Weg zurück durch die History langsam sein.

Git 2.56 bricht den Durchlauf früher ab. Laut Hamanos Ankündigung stoppt Git jetzt, „wenn die exklusiven Commits einer Seite in der Warteschlange erschöpft sind“. Einfach gesagt: Sobald Git nachweisen kann, dass ein Branch nichts mehr beizutragen hat, hört es auf zu suchen.

GitHubs Highlights-Beitrag beziffert die Änderung. Eine merge-base-Abfrage im Linux-Kernel sank von 167.441 Schritten in 0,29 Sekunden auf 3.887 Schritte in 0,01 Sekunden. In zwei großen Monorepos maß GitHub in einem eine 70-fache Beschleunigung und im anderen eine durchschnittlich 20-fache.

Eine verwandte Änderung verwendet frühere Antworten innerhalb von Befehlen wie git branch --contains wieder, der die Branches auflistet, die einen bestimmten Commit enthalten. Das beschleunigt die Prüfungen, mit denen Git feststellt, ob ein Commit einen anderen erreichen kann.

Kleinere Repositories dank Path-Walk-Repacks

Git speichert die History in Pack-Dateien, also komprimierten Bündeln von Objekten. Ein Repack schreibt diese Bündel neu, um Platz zu sparen. Die Option --path-walk sammelt Objekte Dateipfad für Dateipfad, bevor sie komprimiert, sodass Versionen derselben Datei miteinander verglichen werden.

In GitHubs Test mit dem Repository von Fluent UI schrumpfte der Pack von 558,5 MB auf 164,4 MB. Das sind etwa 71 % weniger. In 2.56 funktionieren Path-Walk-Repacks auch mit Reachability-Bitmaps und Delta-Islands. Git-Server nutzen diese beiden Funktionen, um Klone schnell zu starten und Forks, die sich Speicher teilen, voneinander getrennt zu halten.

Partial Clones können große Dateien wieder abwerfen

Ein Partial Clone lädt die History herunter, ohne jede große Datei mitzunehmen. Er holt Blobs, Gits Wort für Dateiinhalte, erst dann, wenn ein Befehl sie braucht. Mit der Zeit häufen sich diese geholten Dateien auf der Festplatte an.

Git 2.56 bietet eine Möglichkeit, sie zu entfernen. Laut der Release-Ankündigung löscht git repack mit --drop-filtered lokale Blobs oberhalb einer Größengrenze, die der Server weiterhin liefern kann. GitHubs Beitrag nennt ein vollständiges Beispiel: git repack -a --filter=blob:limit=1m --drop-filtered. Es ist ein manueller Schritt, keine automatische Bereinigung.

Sicherere Konfliktlösungen und übersichtlichere Logs

git add --resolved staged nur die Dateien, deren Merge-Konflikte Sie gelöst haben. Die finale Version prüft diese Dateien außerdem auf übrig gebliebene Konfliktmarker, die <<<<<<<-Zeilen, die Git in eine Datei mit Konflikt schreibt. Dadurch rutscht eine halb reparierte Datei schwerer in einen Commit.

git log --follow verfolgt eine Datei jetzt besser durch eine History mit mehreren Umbenennungen und Merges. git log --graph rückt Root-Commits ein, also die ohne Parent, damit getrennte Historien hervortreten. Das steuern die Option --no-graph-indent oder die Einstellung log.graphIndent.

Was nach 2.56 kommt

Die nächste Version wird nicht 2.57 heißen. GitLab-Ingenieur Karthik Nayak schreibt, dass Git im Dezember 2026 auf 2.98 springen will. Git 2.99 und Git 3.0 sind für das Frühjahr 2027 geplant. „Dieser deutliche Sprung dient sowohl Downstream-Maintainern als auch Nutzern als Hinweis darauf, dass eine große Änderung bevorsteht“, schreibt Nayak.

Diese Änderung ist der Wechsel von Git 3.0 zu SHA-256 und reftable als Standard, dazu Rust als Pflichtbestandteil des Builds.

Was das für Entwickler bedeutet

Die meisten Entwickler erhalten die merge-base-Beschleunigung schon durch ein Upgrade. Sie zählt am meisten in großen Monorepos und in CI-Jobs, die viele Male am Tag rebasen oder Branches vergleichen. Wenn Ihre Pipeline ein älteres Git in einem Container-Image festschreibt, steht genau diese Festlegung zwischen Ihnen und dem Gewinn.

Probieren Sie git add --resolved aus, wenn ein Merge das nächste Mal an Konflikten stoppt. Es ersetzt die Gewohnheit, mitten im Merge git add . auszuführen. Das staged neben den Korrekturen auch jede verirrte Änderung im Arbeitsverzeichnis.

Wenn Sie einen Git-Server betreiben oder große Mirrors pflegen, testen Sie --path-walk an einer Kopie eines Repositorys und vergleichen Sie die Pack-Größen. Das Ergebnis von Fluent UI stammt aus einem einzigen Repository, und Ihre Mischung an Dateien wird anders sein. Messen Sie, bevor Sie einen produktiven Repack-Job ändern.

Planen Sie schließlich für den Versionssprung. Ein Skript, das die Ausgabe von git --version vergleicht und als Nächstes 2.57 erwartet, bekommt stattdessen 2.98. Prüfen Sie diese Vergleiche jetzt, solange die Änderung noch Monate entfernt ist.