Git 2.56 veröffentlicht: sicherere Konfliktauflösung und schnellere Merge-Base

Das Git-Projekt hat am 28. September 2026 die Version 2.56.0 veröffentlicht. Relevant ist das Update vor allem für Entwicklerteams, die regelmäßig Merge-Konflikte auflösen, und für Betreiber eigener Git-Server mit großen Repositories. Eine Sicherheitslücke mit Notfallcharakter schließt das Release laut den offiziellen Release Notes nicht, heute muss also niemand hektisch patchen.

Wer Git nur als Client auf dem Entwicklerrechner nutzt, bekommt das Update ohnehin über Distribution, Homebrew oder Git for Windows im normalen Rhythmus. Handlungsbedarf besteht eher bei Admins, die Build-Skripte, CI-Pipelines oder Hooks pflegen: Zwei geänderte Standardverhalten können Skripte beeinflussen, die Git-Ausgaben oder Exit-Codes auswerten. Das gehört in das nächste reguläre Wartungsfenster, nicht in eine Sofortmaßnahme.

Was ist passiert?

Maintainer Junio C Hamano hat Git v2.56.0 auf der Git-Mailingliste angekündigt. Laut Ankündigung umfasst das Release 748 Commits ohne Merges seit Version 2.55.0, beigesteuert von 104 Personen, darunter 39 neue Mitwirkende. Der Tag v2.56.0 liegt im offiziellen Repository, die Tarballs stehen wie gewohnt auf kernel.org bereit. GitHub hat parallel einen ausführlichen Überblick von Elijah Newren veröffentlicht, dem Entwickler der Standard-Merge-Strategie merge-ort.

Die wichtigsten Neuerungen laut Release Notes und GitHub-Blog:

• git add --resolved: staged nur Pfade, die gerade als Konflikt im Index stehen. Vorher prüft Git diese Dateien auf übrig gebliebene Konfliktmarker. Findet es einen, bricht der Befehl ab und lässt den Index unverändert. Unabhängige lokale Änderungen bleiben ungestaged.
• git branch --delete-merged: löscht lokale Branches in einem Rutsch, deren Stand bereits im zugehörigen Remote-Tracking-Branch enthalten ist. Mit --dry-run zeigt Git nur an, was gelöscht würde. Per branch.<name>.deleteMerged = false lassen sich einzelne Branches schützen.
• git refs: Der Werkzeugkasten für Referenzen kennt jetzt create, update, delete und rename, optional mit Vergleich gegen einen erwarteten alten Wert.
• git history drop: Der weiterhin experimentelle Befehl entfernt einen Commit und spielt die Nachfolger auf dessen Elternteil neu ein. Bei Konflikten bricht er ab.
• git bisect --reset-when-found: setzt die Bisect-Sitzung nach dem Fund automatisch zurück, wahlweise auf den Ausgangsstand oder auf den gefundenen Commit.
• git repack --drop-filtered: löscht in Partial Clones lokal zwischengespeicherte große Blobs, die sich später wieder vom Promisor-Remote holen lassen. Aktuell nur mit blob:limit-Filtern.
• git replay --linearize: spielt Historie ohne Merge-Commits linear ab, vergleichbar mit git rebase --no-rebase-merges, aber ohne Arbeitsverzeichnis.

Für wen ist das relevant?

Das Release richtet sich an drei Gruppen mit unterschiedlichem Nutzen:

• Entwicklerteams und Maintainer: git add --resolved ersetzt das riskante git add -u nach einem Merge. Bisher konnte man damit versehentlich unabhängige lokale Änderungen oder Dateien mit vergessenen Konfliktmarkern committen.
• Betreiber eigener Git-Server wie Gitea, Forgejo oder GitLab: Die Performance-Arbeiten an Merge-Base-Berechnung, Reftable und Packfiles wirken sich serverseitig aus, sobald die Plattform eine neue Git-Version mitbringt.
• Admins mit CI- und Build-Automatisierung: geänderte Standardausgaben und Exit-Codes können Skripte betreffen.

Weniger relevant ist Git 2.56 für Anwender, die Git nur über eine grafische Oberfläche oder eine IDE mit eigener Git-Bibliothek nutzen. Dort hängt der Nutzen davon ab, ob und wann das Werkzeug die neue Version einbindet.

Performance für große Repositories

Der größte Teil der Arbeit steckt laut Release Notes in internen Optimierungen. GitHub nennt dazu konkrete Messwerte, die aus eigenen Tests des Projekts stammen und nicht unabhängig nachgemessen wurden:

• Merge-Base: Die Suche nach gemeinsamen Vorfahren stoppt früher, sobald keine weitere Merge-Base mehr möglich ist. In einem Monorepo-Fall sank die Zeit von 0,68 auf 0,01 Sekunden, im Linux-Kernel für git merge-base --all v4.8 v4.9 von 0,29 auf 0,01 Sekunden.
• Path-Walk-Repacks: funktionieren jetzt zusammen mit Reachability-Bitmaps und Delta Islands. In einem Benchmark mit dem Fluent-UI-Repository schrumpfte ein Pack von 558,5 MB auf 164,4 MB. Standardmäßig aktiv ist Path-Walk aber weiterhin nicht.
• Quadratische Fallen beseitigt: Bei 37.815 Packfiles dauerte ein Befehl zuvor 4,5 Sekunden, ein bestimmter git diff auf einem Chromium-Checkout mit rund 500.000 Indexeinträgen sank laut GitHub von etwa acht Minuten auf 0,07 Sekunden.
• Branch- und Tag-Abfragen: git branch --contains und git for-each-ref --contains nutzen jetzt die schnellere Traversierung, die bisher nur git tag --contains kannte.

Wie kritisch ist das?

Git 2.56 ist ein reguläres Feature-Release, kein Sicherheitsupdate. Die Release Notes führen allerdings einige Korrekturen mit Sicherheitsbezug auf, die man kennen sollte. Git for Windows ermittelt den Typ eines symbolischen Links nicht mehr automatisch, wenn das Ziel mit einem Schrägstrich beginnt. Damit soll verhindert werden, dass präparierte Repositories mit Symlinks auf Netzwerkfreigaben beim Auschecken NTLM-Anmeldedaten preisgeben. Eine CVE-Nummer nennen die Release Notes dafür nicht. Dazu kommen gehärteter Code gegen beschädigte Reftable-Dateien und beschädigte Trees im Merge-Backend ort sowie ein Fix im Credential Helper wincred, der beim Speichern von OAuth-Tokens Anmeldedaten stillschweigend verlieren konnte.

Für Skripte wichtig sind zwei Verhaltensänderungen. Erstens beenden sich git -h und die Hilfe der meisten Unterbefehle jetzt mit Exit-Code 0 statt 129. Zweitens rückt git log --graph Root-Commits standardmäßig ein, damit sie nicht fälschlich mit darüber stehenden Commits verbunden wirken. Die alte Darstellung liefert --no-graph-indent oder die Konfiguration log.graphIndent.

Richtung Git 3.0 stellen die Release Notes klar, dass Rust-Unterstützung seit 2.55 standardmäßig aktiv, aber noch optional ist und mit Git 3.0 verpflichtend wird. Für Pakete, die Git selbst bauen, ist das ein Planungspunkt. Zusätzlich formuliert Git die Hinweise bei veralteten Befehlen nun deutlicher: Die Entscheidung zur Entfernung ist endgültig. Unter Windows wechselt der Build laut Release Notes von der MINGW64- auf die UCRT64-Laufzeit.

Was sollten Admins jetzt tun?

• Installierte Git-Versionen inventarisieren: auf Servern, Build-Agenten und Container-Images git --version abfragen und notieren, welche Paketquelle jeweils zuständig ist.
• CI-Skripte und Hooks nach Auswertungen von Exit-Code 129 bei Hilfeaufrufen durchsuchen und anpassen.
• Skripte, die git log --graph parsen, mit Git 2.56 testen oder vorsorglich --no-graph-indent setzen.
• Windows-Clients mit Git for Windows zeitnah auf das passende 2.56-Release heben, sobald es bereitsteht, vor allem wenn Repositories aus fremden Quellen ausgecheckt werden.
• Entwicklerteams auf git add --resolved als sicheren Standard nach Merge-Konflikten hinweisen.
• Bei selbst gebautem Git die Rust-Toolchain in der Build-Umgebung einplanen, da sie mit Git 3.0 Pflicht wird.
• Betreiber großer Repositories: Path-Walk-Repacks in einer Testumgebung prüfen, bevor sie produktiv genutzt werden.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist Git 2.56 ein solides Pflegeupdate ohne Druck. Der unmittelbare Gewinn im Alltag ist git add --resolved, weil es eine häufige Fehlerquelle bei Merges abfängt. Die Performance-Verbesserungen spüren vor allem Teams mit sehr großen Repositories oder Monorepos. Bei typischen KMU-Projekten mit überschaubarer Historie fallen sie kaum ins Gewicht.

Wichtiger ist die Pflege der Automatisierung. Wer Git in Deployments, Backup-Skripten oder CI nutzt, sollte das Update zuerst auf einem Build-Agenten testen. Auf selbst betriebenen Git-Servern kommt die neue Version meist erst über ein Plattform-Update an. Hier lohnt ein Blick in die Release Notes der eigenen Plattform, statt Git am Paketmanager vorbei zu aktualisieren.

Passende Anleitungen auf S-EDV

• Gitea als selbst gehosteter Git-Server mit Docker: eigener Git-Server für kleine Teams.
• GitLab CE mit Docker als DevOps-Plattform: für Teams, die CI/CD direkt am Repository brauchen.
• Gitleaks als Secret-Scanner im Docker-Container: Zugangsdaten in Git-Repositories aufspüren.

Quellen

• Git v2.56 Release Notes im offiziellen Repository
• LWN: Git v2.56.0 veröffentlicht, inklusive Ankündigung von Junio C Hamano vom 28.09.2026
• GitHub-Blog: Highlights from Git 2.56 (28.09.2026)
• Linuxiac: Git 2.56 mit sichererer Konfliktauflösung und Performance-Gewinnen
• Tag v2.56.0 im Git-Repository auf GitHub