- Git, das von Entwicklerinnen und Entwicklern weltweit genutzt wird, treibt strukturelle Veränderungen voran, um sich auf die kommenden zehn Jahre vorzubereiten. Im Mittelpunkt der wichtigsten Umbauten stehen Sicherheit, Skalierbarkeit und Benutzerfreundlichkeit
- Die auffälligste Veränderung ist der Wechsel von SHA-1 zu SHA-256. Bis 2030 soll die Nutzung von SHA-1 verboten werden, doch die Einführung verzögert sich wegen mangelnder Unterstützung im Ökosystem
- Mit der Einführung von Reftable wird versucht, Hunderte Millionen Referenzen effizient zu verwalten und Einschränkungen des Dateisystems sowie Nebenläufigkeitsprobleme zu lösen
- Zur Verbesserung der Verarbeitung großer Dateien werden Large-object promisors und eine pluggbare Objektdatenbank entwickelt; eine schrittweise Integration in Versionen nach Git 2.50 läuft bereits
- Unter dem Einfluss neuer Versionsverwaltungssysteme wie Jujutsu will Git moderne Workflows durch eine vereinfachte UI und neue Befehle unterstützen
Warum Git sich verändern muss
- Seit seiner Veröffentlichung im Jahr 2005 hat sich Git in 20 Jahren zu einem zentralen Werkzeug entwickelt, auf das Millionen von Repositories und unzählige Skripte angewiesen sind
- Doch durch Veränderungen im Umfeld wie Sicherheitslücken in SHA-1, das Wachstum großer Repositories und die Verbreitung von CI-Pipelines wurden strukturelle Grenzen sichtbar
- Bei SHA-1 wurde 2017 durch den SHAttered-Angriff von CWI und Google die Möglichkeit von Kollisionen nachgewiesen
- Durch die gestiegene GPU-Rechenleistung ist inzwischen ein Niveau erreicht, auf dem große Organisationen Hash-Kollisionen berechnen können
- Git muss statt einer radikalen Neugestaltung eine schrittweise Evolution wählen und treibt den Wandel bei gleichzeitiger Kompatibilität mit dem bestehenden Ökosystem voran
Umstellung auf SHA-256
- In Git 2.29 (Oktober 2020) wurde SHA-256-Unterstützung hinzugefügt, große Plattformen wie GitHub unterstützen sie jedoch noch nicht
- Git, Dulwich und Forgejo unterstützen sie vollständig, GitLab, go-git und libgit2 befinden sich bei der Unterstützung noch im experimentellen Stadium
- SHA-1 wird zwar nur zur einfachen Integritätsprüfung verwendet, doch das gesamte Ökosystem — etwa Signaturen, CI und Skripte — arbeitet unter der Annahme von Kollisionsresistenz
- Aufgrund staatlicher und unternehmensinterner Vorgaben muss SHA-1 bis 2030 entfernt werden; in Git 3.0 soll SHA-256 zum Standardwert werden
- Für die Umstellung des Ökosystems wird Nutzerinnen und Nutzern empfohlen, sich durch Tests von Tools und Anfragen nach Forge-Unterstützung zu beteiligen
Einführung von Reftable
- Bisher verwendet Git eine Loose-Reference-Struktur, bei der jede Referenz als separate Datei gespeichert wird
- In Repositories mit zig Millionen Referenzen ist das ineffizient; außerdem treten Probleme mit Groß-/Kleinschreibung im Dateisystem und Inkonsistenzen bei Nebenläufigkeit auf
- Reftable ist eine tabellenbasierte Struktur auf Basis eines Binärformats, die atomare Updates und eine effiziente Verwaltung von Referenzen ermöglicht
- Im Fall eines GitLab-Repositories mit 20 Millionen Referenzen musste die bisherige
packed-refs-Datei jeweils mit 2 GB neu geschrieben werden
- In Git 3.0 wird Reftable zum Standard-Backend; empfohlen wird, Git-Befehle statt direkter Dateizugriffe zu verwenden
Verbesserungen bei der Verarbeitung großer Dateien
- Git ist beim Komprimieren von Textdateien effizient, bei Änderungen an Binärdateien entsteht jedoch Ineffizienz, weil das gesamte Objekt neu erzeugt werden muss
- Laut einer GitLab-Analyse entfallen 75 % des Repository-Speicherplatzes auf Binärdateien ab 1 MB
- Die Funktion Large-object promisors speichert große Objekte in einem separaten Remote-Speicher und ermöglicht die Übertragung über ein CDN oder eine S3-API
- In Git 2.50 bis 2.52 wurde die Protokollimplementierung abgeschlossen; die clientseitige Nutzung ist nun möglich
- Eine pluggbare Objektdatenbank soll ein binärdateispezifisches Speicherformat einführen und inkrementelle Speicherung unterstützen
- In Git 2.53 wurde eine integrierte Schnittstelle für Objektdatenbanken eingeführt, für 2.54 wird ein Proof of Concept (PoC) erwartet
Verbesserungen an der Benutzeroberfläche
- Git-Befehle stehen seit langem in der Kritik, komplex und inkonsistent zu sein; als Alternative gewinnt das auf Rust basierende Jujutsu (JJ) an Bedeutung
- Jujutsu bietet automatische Neuplatzierung der Historie, die Behandlung von Konflikten als Daten und einen Ansatz, Commits wie Entwürfe zu behandeln
- Git übernimmt nun einige Vorteile von Jujutsu, ohne bestehende Workflows zu zerstören
- In Git 2.54 sollen die Befehle
git history split und git history reword hinzukommen
- Künftig sollen weitere Subkommandos zur Bearbeitung der Historie ergänzt werden
- Steinhardt betont, dass Git durch Wettbewerb lernt und dass die Modernisierung der UI und Verbesserungen der Benutzerfreundlichkeit voranschreiten
Noch keine Kommentare.