Der derzeitige Plan für Git 3.0 sieht SHA-256, Reftable und main als Standards für neu angelegte Repositories vor. Rust soll beim Kompilieren des Git-Clients zur Build-Abhängigkeit werden. Bestehende SHA-1-Repositories sollen weiter funktionieren, und ein Veröffentlichungstermin ist nicht angekündigt. Die Git 3.0 Changes erfordern deshalb keine überstürzte Migration, wohl aber einen kontrollierten Kompatibilitätstest.
Ein isoliertes Testlabor ist die beste Vorbereitung auf Git 3.0, weil es Fehler in Skripten, CI/CD-Pipelines und Repository-Tools aufdeckt, ohne produktive Repositories zu verändern. Das Labor bildet den vollständigen Weg vom lokalen Commit bis zur Wiederherstellung ab.
Wo entstehen Kompatibilitätsrisiken durch Git 3.0?
Fest codierte Annahmen über Objekt-IDs, Referenzdateien oder den Namen des initialen Branches verursachen die meisten absehbaren Fehler. Betroffen sind vor allem neue Repositories und Anwendungen, die Git-Interna direkt auslesen.
Der Prüfpfad beginnt beim lokalen Commit und endet nach Build, Analyse, Deployment und Wiederherstellung. In den Testumfang gehören:
- die Git-Clients auf Entwicklungsrechnern und administrativen Arbeitsplätzen
- die virtuellen Maschinen, Container-Images und Build-Runner
- die CI/CD-Systeme und gemeinsam genutzten Pipeline-Vorlagen
- die IDEs, Plug-ins und grafischen Git-Clients
- die Hooks auf Clients und Servern
- die Repository-Browser, Sicherheits-Scanner und Archivierungswerkzeuge
- die Backup- und Wiederherstellungssysteme
- die Remote-Plattformen und deren Automatisierungs-APIs
Die anschließende Inventur zeigt, welche Git-Version oder Git-Implementierung jede dieser Komponenten verwendet.
Git-Versionen und Abhängigkeiten inventarisieren
git --version liefert nur die installierte Version. Für reproduzierbare Tests braucht die Matrix auch das Betriebssystem, die Installationsquelle und bei Containern das konkrete Image. Ein zweiter Befehl gibt bei selbst kompilierten Installationen zusätzliche Build-Informationen aus:
git --version
git version --build-optionsDie Matrix erfasst jede Installation auf Arbeitsplätzen, Servern und Runnern. Bei Containern gehören der Image-Name und der unveränderliche Image-Digest dazu. Für Installationen über APT, DNF oder Homebrew werden auch der Paketmanager, das eingebundene Paket-Repository und die Paketversion dokumentiert.
Manche Anwendungen rufen das Git-Kommando auf, andere verwenden Bibliotheken wie libgit2 oder JGit. IDE-Plug-ins, Scanner und Deployment-Werkzeuge benötigen deshalb einen eigenen Eintrag mit ihrer jeweiligen Versionsnummer. Die Schulung zu Git, GitLab und CI/CD behandelt das Zusammenspiel von lokalen Clients, Remote-Repositories, Runnern und IDE-Integrationen.
Mit dieser Bestandsaufnahme lässt sich das Test-Repository aus denselben Komponenten zusammensetzen, die später produktiv arbeiten.
Ein isoliertes Git-SHA-256-Repository anlegen
Git unterstützt SHA-256 und Reftable bereits als wählbare Repository-Formate. Eine Installation eignet sich für den kombinierten Test, wenn git init -h die Optionen --object-format und --ref-format aufführt. Das Labor entsteht anschließend mit diesem Befehl:
git init --object-format=sha256 --ref-format=reftable -b main git3-labDas Labor-Repository bleibt von produktiven Remotes getrennt. Die Interoperabilität zwischen SHA-1- und SHA-256-Repositories ist noch nicht vollständig, weshalb ungeprüfte Übertragungen fehlschlagen oder unvollständige Testergebnisse liefern können.
Ein leeres Repository deckt nur Fehler bei der Initialisierung auf. Für einen aussagekräftigen Test braucht es:
- mehrere Commits mit repräsentativen Pfaden und Dateigrößen
- mehrere Branches
- leichte und annotierte Tags
- ein lokales Bare-Repository als Test-Remote
- die im Projekt verwendeten Hooks
- eine Kopie der CI/CD-Konfiguration ohne produktive Zugangsdaten
Die 64-stelligen SHA-256-Objekt-IDs liefern danach den ersten Belastungstest für die angebundenen Systeme.
SHA-256-Objekt-IDs in der Werkzeugkette testen
SHA-1-Objekt-IDs bestehen aus 40 hexadezimalen Zeichen, SHA-256-Objekt-IDs aus 64. Reguläre Ausdrücke, Datenbankspalten und API-Schemata können deshalb unbemerkt auf 40 Zeichen begrenzt sein. Eine Quelltextsuche sollte unter anderem folgende Muster erfassen:
\b[0-9a-f]{40}\b
VARCHAR(40)
maxLength: 40git rev-parse HEAD gibt die aktuelle Objekt-ID aus. Der Prüfpfad führt diesen Wert durch jede erfasste Komponente:
- die IDE und den grafischen Git-Client
- den Repository-Browser und den Sicherheits-Scanner
- das Build-System und die Hooks
- das Backup- und Wiederherstellungssystem
- die angebundenen APIs
Anwendungen sollten Objekt-IDs als undurchsichtige Zeichenfolgen behandeln, sofern sie keine kryptografische Verarbeitung vornehmen. Auch gekürzte Objekt-IDs besitzen keine dauerhaft festgelegte Länge.
Ein Datenaustausch zwischen SHA-1- und SHA-256-Repositories gehört erst nach einem getrennten Interoperabilitätstest in den Freigabeplan. Der Test bildet alle tatsächlich verwendeten Vorgänge ab, etwa Push und Fetch, die Übertragung von Tags, Submodule sowie die Wiederherstellung.
Git Reftable: direkte Zugriffe auf Git-Interna prüfen
Bei Reftable liegen Branches, Tags und Reflogs nicht mehr in der bisher erwarteten Datei-Struktur aus .git/refs, packed-refs und einzelnen Reflog-Dateien. Skripte, die diese Pfade direkt durchlaufen, können Referenzen übersehen oder mit einem Fehler abbrechen.
Für formatunabhängige Auswertungen stehen git for-each-ref, git show-ref und git reflog bereit. Backup-, Analyse- und Deployment-Werkzeuge benötigen trotzdem einen eigenen Test mit einem Reftable-Repository.
Wenn die installierte Git-Version den Unterbefehl unterstützt, simuliert der folgende Trockenlauf die Migration eines bestehenden Test-Repositorys:
git refs migrate --ref-format=reftable --dry-runDer Trockenlauf schreibt den migrierten Referenzspeicher nach .git/ref_migration.reftable und lässt das aktive Referenzformat unverändert. Er bestätigt damit die Übersetzung der Referenzen, ersetzt aber keinen Anwendungstest mit einem tatsächlich als Reftable initialisierten Repository.
Nach den Dateizugriffen bleibt die fest codierte Annahme eines Branches namens master als nächster Prüfpunkt.
Fest codierte Verweise auf master finden
Git 3.0 soll main als initialen Branch-Namen verwenden. Installationsskripte, Pipeline-Vorlagen, Deployment-Jobs und Branch-Schutzregeln können weiterhin wörtliche Verweise auf master enthalten. Eine Quelltextsuche mit ripgrep liefert dafür einen ersten Fundbestand:
rg -n '(^|[^[:alnum:]_])master([^[:alnum:]_]|$)' .Die Trefferliste ist eine Inventur und noch kein Fehlernachweis. Historische Dokumentation oder Migrationsskripte dürfen den Namen absichtlich enthalten, während Branch-Filter und Deployment-Regeln meist angepasst werden müssen.
Einstellungen der Remote-Plattform liegen häufig außerhalb des Repository-Inhalts. Der Test legt deshalb neue Repositories über die Kommandozeile, die IDE, die Plattformoberfläche und die Automatisierungs-API an. git symbolic-ref --short HEAD zeigt danach den tatsächlich erzeugten initialen Branch.
Die Schulung zu Continuous Integration und Delivery mit GitLab behandelt Branch-Filter, Runner und Deployment-Regeln in Build- und Release-Abläufen.
Neben den Repository-Formaten verändert Git 3.0 voraussichtlich die Voraussetzungen für Teams, die Git selbst kompilieren.
Wen betrifft die geplante Rust-Abhängigkeit?
Die geplante Rust-Abhängigkeit betrifft das Kompilieren von Git. Wer ein vorgefertigtes Git-Paket über das Betriebssystem oder einen Paketmanager installiert, benötigt deshalb nicht automatisch rustc und Cargo auf dem Arbeitsplatz.
Relevant wird die Änderung für Teams, die Git-Pakete für Linux-Distributionen bauen, interne Paketquellen betreiben oder angepasste Git-Builds erzeugen. Die Inventur erfasst dort die Versionen von rustc und Cargo, den verwendeten Compiler, das Build-Image und die Paketdefinition.
Die Befunde zu Objektformat, Referenzformat, Branch-Konvention und Build-Kette laufen anschließend in einer gemeinsamen Kompatibilitätsmatrix zusammen.
Kompatibilitätsmatrix auswerten und nächste Schritte planen
Jede Zeile beschreibt eine konkrete Komponente mit Version, Umgebung und Installationsquelle. Vier Statuswerte reichen für die Auswertung: kompatibel, bedingt kompatibel, inkompatibel und noch nicht getestet. Bei einer bedingten Freigabe nennt die Matrix die benötigte Konfiguration oder Mindestversion.
| Komponente | Version | Umgebung und Quelle | SHA-256 | Reftable | main |
Zugriff auf Git-Interna | Rust-Build | Status und Verantwortung |
|---|---|---|---|---|---|---|---|---|
| Entwicklungs-Image | Eintragen | Image-Digest und Paketquelle | Noch nicht getestet | Noch nicht getestet | Noch nicht getestet | Prüfen | Nicht relevant oder prüfen | Eintragen |
| CI/CD-Runner | Eintragen | Betriebssystem oder Image-Digest | Noch nicht getestet | Noch nicht getestet | Noch nicht getestet | Prüfen | Nicht relevant oder prüfen | Eintragen |
| Repository-Scanner | Eintragen | Plattform und Installationsquelle | Noch nicht getestet | Noch nicht getestet | Nicht relevant oder prüfen | Prüfen | Nicht relevant | Eintragen |
Gemeinsam genutzte Pipeline-Vorlagen, zentrale Repository-Dienste, Backup-Systeme und weit verbreitete Entwicklungswerkzeuge erhalten zuerst einen Test, weil ein Fehler dort mehrere Projekte betrifft. Ein neuer Testlauf folgt, sobald sich die Git-Vorabversion, die Remote-Plattform oder eine kritische Integration ändert.
Das Labor trifft keine Aussage über den Erscheinungstermin von Git 3.0. Es belegt stattdessen für jede Komponente, ob SHA-256, Reftable und main im vollständigen Arbeitsablauf funktionieren. Grundlagen zur Repository-Struktur, zu Branches, Tags und Remotes vermittelt die Schulung zur Versionskontrolle mit Git.
Eine ausgefüllte Matrix trennt bestätigte Kompatibilität von bloßen Annahmen. Lege zunächst ein isoliertes Repository an und dokumentiere einen vollständigen Weg vom Commit bis zur Wiederherstellung.