{"id":141016,"date":"2025-08-19T11:11:54","date_gmt":"2025-08-19T09:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51"},"modified":"2025-08-19T11:11:54","modified_gmt":"2025-08-19T09:11:54","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","title":{"rendered":"Ver\u00f6ffentlichung des Quellcode-Management-Systems Git 2.51","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach zwei Monaten Entwicklung wird die Ver\u00f6ffentlichung des verteilten Systems zur Verwaltung von Quelltexten Git 2.51 vorgestellt. Git zeichnet sich durch hohe Leistung aus und bietet Mittel f\u00fcr die nichtlineare Entwicklung, die auf Verzweigungen und das Zusammenf\u00fchren von Branches basieren. Um die Integrit\u00e4t der Historie und die Stabilit\u00e4t gegen\u00fcber r\u00fcckblickenden \u00c4nderungen zu gew\u00e4hrleisten, wird ein implizites Hashing der gesamten vorhergehenden Historie in jedem Commit verwendet, sowie die Verifizierung durch digitale Signaturen der Entwickler f\u00fcr einzelne Tags und Commits. Der Code von Git wird unter der GPLv2+-Lizenz ver\u00f6ffentlicht. <\/p>\n
Im Vergleich zur vorherigen Version wurden 506 \u00c4nderungen in die neue Version aufgenommen, die mit Beteiligung von 91 Entwicklern erstellt wurden (21 davon haben zum ersten Mal an der Entwicklung von Git teilgenommen). Die wichtigsten Neuerungen (1, 2, 3): <\/p>\n
\n
Die Leistung der Kommandos \u201egit push\u201c und \u201egit fetch\u201c wurde in Repositories mit einer hohen Anzahl von Referenzen verbessert. Die Beschleunigung wurde durch die Aktualisierung der Referenzen im Batch-Modus erreicht, wobei in einer Transaktion mehrere Referenzen verarbeitet werden, anstatt f\u00fcr die Aktualisierung jeder einzelnen Referenz eine eigene Transaktion zu erstellen. Diese Optimierung hat die Geschwindigkeit des \u201ereftable\u201c-Backends erheblich erh\u00f6ht, das nun das \u201efiles\u201c-Backend in der Leistung \u00fcbertrifft. Beispielsweise hat sich in einem Test-Repository mit 10.000 Referenzen die Leistung von \u201egit fetch\u201c bei Verwendung des \u201ereftable\u201c-Backends um das 22-fache erh\u00f6ht, w\u00e4hrend das \u201efiles\u201c-Backend nur um das 1,25-fache gesteigert wurde. F\u00fcr \u201egit push\u201c betrug der Zuwachs 18 und 1,21-fach.\n
Ein neues Verfahren zur Verpackung in Pack-Dateien von Teilen des Repositories, die nicht mit dem Tracking unerreichbarer Objekte verbunden sind, f\u00fcr die im Repository keine Referenzen existieren (keine Verzweigungen oder Tags verweisen darauf), wurde vorgeschlagen. Informationen \u00fcber unerreichbare Objekte werden in separaten Pack-Dateien (\u201ecruft packs\u201c) gespeichert, was die Notwendigkeit einer Reflexion in den multipack-Indizes (MIDX) zur Abdeckung der urspr\u00fcnglich unerreichbaren Objekte zur Folge hatte, die nur im cruft-Paket gespeichert waren, aber nach dem zugeh\u00f6rigen Commit erreichbar geworden sind.\n
In der neuen Version wird beim Neupacken von Pack-Dateien sichergestellt, dass zus\u00e4tzliche Kopien erreichbarer Objekte, die nur in cruft-Dateien gespeichert sind, erhalten bleiben. Diese \u00c4nderung garantiert, dass im Satz der Pack-Dateien, die zur Speicherung erreichbarer Objekte verwendet werden, keine Objekte enthalten sind, die auf andere Objekte verweisen, die au\u00dferhalb dieses Satzes gespeichert sind. Um unerreichbare Inhalte von cruft-Dateien aus den multipack-Indizes (MIDX) auszuschlie\u00dfen, wurde die Einstellung \u201erepack.MIDXMustContainCruft\u201c vorgeschlagen, die es erm\u00f6glicht, die Gr\u00f6\u00dfe solcher Indizes erheblich zu reduzieren. Die Aktivierung dieser Einstellung in GitHub-Repositories reduzierte die Gr\u00f6\u00dfe der MIDX-Indizes um 38 %, beschleunigte die Schreibvorg\u00e4nge in die MIDX-Indizes um 35 % und erh\u00f6hte die Lesegeschwindigkeit um 5%. <\/p>\n
Im Befehl \u201egit pack-objects\u201c wurde die Option \u201e--path-walk\u201c hinzugef\u00fcgt, die einen neuen Ansatz f\u00fcr die Sammlung von Informationen \u00fcber Objekte beim Neupacken von Pack-Dateien implementiert. Anstatt die Objekte in der Reihenfolge der Revisionen zu durchlaufen, werden im Modus \u201e--path-walk\u201c die Objekte \u00fcber die Durchquerung von Dateipfaden durchlaufen, was es erm\u00f6glicht, alle Objekte mit demselben Dateipfad auf einmal zu verpacken. Dieser Ansatz vermeidet die Heuristik, die Hashing zur Bestimmung der Verbindung eines Objekts zu seinem Dateipfad verwendet, und beseitigt die Notwendigkeit, die Objekte vor dem Verpacken zu sortieren. Im Modus \u201e--path-walk\u201c ist die Gr\u00f6\u00dfe der generierten Pack-Dateien erheblich kleiner als bei der Gruppierung von Objekten mithilfe von Hashes.\n
Ein Format f\u00fcr den Austausch von gespeicherten Zust\u00e4nden des Arbeitsbaums und der Indizes im Repository, die mit dem Befehl \u201egit stash\u201c erstellt werden, wurde definiert. Das neue Format erm\u00f6glicht die Kodierung der gespeicherten \u00c4nderungen (stash-Eintr\u00e4ge) als Sequenz von Commits. F\u00fcr den Import und Export werden die Unterbefehle \u201egit stash import\u201c und \u201egit stash export\u201c angeboten, die verwendet werden k\u00f6nnen, um gespeicherte Zust\u00e4nde von einem System auf ein anderes zu \u00fcbertragen und Push- oder Pull-Operationen mit diesen Zust\u00e4nden wie mit normalen Branches oder Tags auszuf\u00fchren. git stash export \u2014to-ref refs\/stashes\/my-stash git push origin refs\/stashes\/my-stash \u2026 git fetch origin \u2018+refs\/stashes\/*:refs\/stashes\/*\u2019 git stash import refs\/stashes\/my-stash\n
Im Befehl \u201egit cat-file\u201c, der den Inhalt ausgew\u00e4hlter Objekte anzeigt, wurde mit den Optionen \u201e--batch\u201c und \u201e--batch-check\u201c die M\u00f6glichkeit implementiert, Informationen \u00fcber fehlende Objekte anzuzeigen (z. B. aufgrund von Besch\u00e4digungen im Repository) und Submodulen. Fr\u00fcher gab der Befehl \u201egit cat-file --batch-check\u201c bei Angabe eines Pfades zu einem Submodul \u201emissing\u201c aus, zeigt nun aber die Objekt-ID an.\n
Im Befehl \u201egit log\u201c wurden Optimierungen auf Grundlage von Bloom-Filtern implementiert, um die Suche in der \u00c4nderungs-Historie zu beschleunigen, wenn Filter mit mehreren Dateipfaden angegeben werden, z. B. \u201egit log -- path\/to\/a path\/to\/b\u201c.\n
Die Befehle «git switch» und «git restore» wurden stabilisiert, die seit 2019 als experimentell galten. Die Befehle werden als moderne Alternativen zu «git checkout» pr\u00e4sentiert, die solche weniger zusammenh\u00e4ngenden Funktionen wie das Verwalten von Branches (Wechseln und Erstellen) und das Wiederherstellen von Dateien im Arbeitsverzeichnis trennen.\n
Der Befehl «git whatchanged», der \u00e4quivalent zu «git log —raw» ist, wurde f\u00fcr die Version Git 3.0 als veraltet erkl\u00e4rt und soll entfernt werden.\n
Dem Befehl «git for-each-ref» wurde die Option «—start-after» hinzugef\u00fcgt, die zusammen mit der Option «—count» verwendet werden kann, um die paginierte Ausgabe zu organisieren.\n
Den Befehlen «git merge» und «git pull» wurde die Option «—compact-summary» hinzugef\u00fcgt, um ein kompaktes Format f\u00fcr die Zusammenfassung von \u00c4nderungen anstelle des diffstat-Formats zu verwenden.\n
In der Git-Codebasis ist die Verwendung des Schl\u00fcsselworts «bool» erlaubt, das im C99-Standard eingef\u00fchrt wurde. Zudem sind einige C99-Funktionen dokumentiert, die in Git experimentell verwendet werden (zum Beispiel wird f\u00fcr Mitte 2026 geplant, die Verwendung der Konstruktionen «(struct foo){ .member = value };» zuzulassen). Ein C99-kompatibler Compiler ist seit 2021 f\u00fcr Git erforderlich, jedoch werden die Funktionen der C99-Spezifikation sehr vorsichtig eingef\u00fchrt, um die Kompatibilit\u00e4t mit teilweise den Standard unterst\u00fctzenden Compilern zu bewahren.\n
Die Regeln zur Abnahme von Patches wurden ge\u00e4ndert, um das Einreichen von Patches unter einem Pseudonym zu erlauben, nicht nur unter dem echten Namen des Entwicklers. Diese \u00c4nderung entspricht den Patchannahmeregeln f\u00fcr den Linux-Kernel.\n
Die Liste der abw\u00e4rtsinkompatiblen \u00c4nderungen, die in der Version Git 3.0 implementiert werden, wurde aktualisiert. Zu den bedeutenden \u00c4nderungen in der kommenden Ver\u00f6ffentlichung von Git 3.0 geh\u00f6rt der standardm\u00e4\u00dfige Wechsel zu Objektidentifikatoren, die auf dem SHA-256-Hashalgorithmus basieren, bei der Initialisierung neuer Repositories und die Verwendung des Formats «reftable» zur Speicherung von Verweisen auf Branches und Tags im Repository (es wird ein Blob-Speicher aus dem JGit-Projekt verwendet, der f\u00fcr die Speicherung einer sehr gro\u00dfen Anzahl von Verweisen optimiert ist). <\/ul>\n