Git 2.56 bringt history drop und delete-merged

Git 2.56 liegt als Release Candidate vor und wird Ende September 2026 erwartet. LWN.net berichtete, dass die Version mehr als 700 Nicht-Merge-Commits enthält. Die meisten davon sind Unterbau. Eine Handvoll neuer Befehle ändert aber, was Entwickler ohne interaktives Rebase tun können.

LWN nennt 2.56 "eine solide Version" und schreibt, das Projekt halte "einen großen Teil seiner wichtigeren Arbeit für die Zukunft zurück". Diese Zukunft heißt Git 3.0.

Die neuen Befehle

Befehl oder Option	Was er tut
git history drop	Entfernt benannte Commits aus einem Branch, indem die folgenden neu abgespielt werden
git repo info	Gibt Repository-Pfade aus, absolut und relativ
git add --resolved	Staged nur die Merge-Pfade, deren Konflikte Sie gelöst haben
git branch --delete-merged	Löscht lokale Branches, die bereits in ihren Remote-Tracking-Branch gemerged wurden
git bisect --reset-when-found	Stellt den Ausgangszustand wieder her, sobald bisect den Commit findet
git replay --linearize	Verwirft Merge-Commits beim Neuabspielen der History
git refs	Erstellt, löscht, aktualisiert und benennt Referenzen direkt um

Was history drop tut, und wo es aufhört

git history drop entfernt einen benannten Commit aus einem Branch. Es arbeitet, indem es jeden danach folgenden Commit neu abspielt. Das ist die Aufgabe, die man heute mit einem interaktiven Rebase erledigt, sorgfältig getippt, Zeile für Zeile.

Es gibt eine Grenze, die man vorher kennen sollte. Die Release Notes von Git sagen, der Befehl verweigert weiterhin die Arbeit, wenn die History Merge-Commits enthält. Viele echte Branches enthalten Merges. Der Befehl passt also eher zu einem linearen Feature-Branch als zu einem langlebigen gemeinsamen Branch.

git replay --linearize nähert sich demselben Feld von der anderen Seite. Es verwirft Merge-Commits beim Neuabspielen. Das glättet eine verworrene History zu einer geraden Linie.

Kleinere Änderungen, die auffallen

git add --resolved zielt auf ein häufiges Durcheinander mitten im Merge. Während eines Konflikts reparieren Sie oft zwei Dateien und lassen andere Änderungen im Arbeitsverzeichnis. Die neue Option staged nur die Pfade, deren Konflikte Sie gelöst haben, und lässt Ihre übrigen lokalen Änderungen in Ruhe.

git branch --delete-merged räumt lokale Branches weg, die bereits in den Branch gemerged wurden, dem sie folgen. Git gibt außerdem eine klarere Meldung aus, wenn einer dieser Branches gerade für eine Bisection verwendet wird.

Die Release Notes des Git-Projekts listen mehrere stillere Korrekturen. Git erkennt jetzt Tippfehler in Befehlen wie git push origin/main. Eine neue Einstellung fetch.followRemoteHEAD steuert, wie ein Fetch den Standard-Branch der Gegenstelle behandelt. Ein Hilfeaufruf endet nun mit Code 0 statt 129. Das hindert Skripte daran, eine Hilfeanfrage als Fehler zu lesen. Konfigurationsbefehle wiederholen den Versuch bei Kollisionen, was Lock-Fehler reduziert, wenn zwei Befehle gleichzeitig schreiben.

Darunter formatiert git cat-file --batch die Ausgabe schneller, und git log --follow kommt mit nicht-linearer History besser zurecht als zuvor.

Was das für Entwickler bedeutet

Probieren Sie git history drop an einer Kopie eines Branches aus, bevor Sie ihm an einem echten vertrauen. Die Merge-Commit-Einschränkung entscheidet, ob er überhaupt zu Ihrem Arbeitsablauf passt. Führen Sie git log --merges über den Bereich aus, den Sie ändern wollen: Gibt das etwas aus, verweigert der Befehl die Arbeit.

git branch --delete-merged ist der Befehl, den man sich angewöhnen sollte. Die meisten Entwickler sammeln Dutzende alter lokaler Branches an und räumen sie mit einer Shell-Pipeline auf, die sie vor Jahren aus einem Blogbeitrag kopiert haben. Eine eingebaute Option ist sicherer, weil sie den Remote-Tracking-Branch prüft, statt Namen zu vergleichen.

Die Änderung am Exit-Code verdient einen Blick in Ihre eigenen Werkzeuge. Jedes Skript, das 129 als Signal für eine Hilfeanfrage behandelt hat, sieht jetzt 0. Das ist das korrekte Verhalten, aber es ist eine Verhaltensänderung, und sie scheitert leise statt laut.

Nichts davon bricht ein bestehendes Repository. Die Änderungen, die das tun, stecken in der nächsten Version: Git 3.0 stellt neue Repositories auf SHA-256 und reftable um und macht Rust zur nötigen Build-Abhängigkeit. Gits eigenes Dokument zu Breaking Changes nennt für 3.0 weiterhin kein Datum. Betrachten Sie 2.56 als den letzten ruhigen Halt davor.