{"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\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","title":{"rendered":"Ver\u00f6ffentlichung des Versionsverwaltungssystems Git 2.51","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach zwei Monaten Entwicklung wurde die Version 2.51 des verteilten Quelltextverwaltungssystems Git ver\u00f6ffentlicht. Git zeichnet sich durch hohe Leistung aus und bietet Werkzeuge f\u00fcr nichtlineare Entwicklungen, die auf dem Branching und Merging von \u00c4sten basieren. Um die Integrit\u00e4t der Historie und die Widerstandsf\u00e4higkeit gegen 'r\u00fcckwirkende' \u00c4nderungen zu gew\u00e4hrleisten, wird die gesamte vorherige Historie in jedem Commit implizit gehasht, und auch digitale Signaturen der Entwickler werden f\u00fcr einzelne Tags und Commits verwendet. Der Git-Code wird unter der GPLv2+-Lizenz vertrieben. <\/p>\n
Im Vergleich zur vorherigen Version wurden in die neue Version 506 \u00c4nderungen aufgenommen, die mit der Teilnahme von 91 Entwicklern vorbereitet wurden (21 waren zum ersten Mal an der Entwicklung von Git beteiligt). Die wichtigsten Neuerungen (1, 2, 3): <\/p>\n
\n
Die Leistung der Befehle 'git push' und 'git fetch' in Repositories mit einer gro\u00dfen Anzahl von Referenzen wurde erh\u00f6ht. Die Beschleunigung erfolgt durch das Aktualisieren von Referenzen im Batch-Modus, bei dem mehrere Referenzen in einer Transaktion verarbeitet werden, anstatt f\u00fcr jede Referenz eine separate Transaktion zur Aktualisierung zu erstellen. Diese Optimierung hat die Geschwindigkeit des 'reftable'-Backends erheblich gesteigert, das jetzt das 'files'-Backend in der Performance \u00fcbertrifft. Beispielsweise wurde in einem Testrepository mit 10.000 Referenzen die Leistung von 'git fetch' beim Einsatz des 'reftable'-Backends 22-mal erh\u00f6ht, w\u00e4hrend es beim 'files'-Backend nur um 1,25-mal gesteigert wurde. F\u00fcr 'git push' betrug die Steigerung 18- bzw. 1,21-mal.\n
Es wurde eine neue Methode zum Packen von Repositoryteilen in Pack-Dateien vorgeschlagen, die nicht mit dem Tracking unerreichbarer Objekte, auf die im Repository keine Referenzen (keine Branches oder Tags) verweisen, verbunden sind. Informationen \u00fcber unerreichbare Objekte werden in separaten Pack-Dateien ('cruft packs') gespeichert, was die Notwendigkeit zu deren Darstellung in mehrpack-Indexen MIDX (multi-pack index) mit sich brachte, um Objekte zu erfassen, die urspr\u00fcnglich unerreichbar waren und nur im Cruft-Paket gespeichert wurden, aber nach einem darauf verweisenden Commit erreichbare wurden.\n
In der neuen Version wird beim Repacken von Pack-Dateien sichergestellt, dass zus\u00e4tzliche Kopien erreichbarer Objekte, die nur in Cruft-Dateien gespeichert sind, erhalten bleiben. Diese \u00c4nderung garantiert, dass der Satz von Pack-Dateien, der zur Speicherung erreichbarer Objekte verwendet wird, keine Objekte enth\u00e4lt, die auf andere Objekte verweisen, die au\u00dferhalb dieses Satzes gespeichert sind. Um unerreichbare Inhalte von Cruft-Dateien aus mehrpack-Indices (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 der Einstellung in einem GitHub-Repository f\u00fchrte zu einer Reduzierung der Gr\u00f6\u00dfe von MIDX-Indizes um 38 %, einer Beschleunigung des Schreibvorgangs in MIDX-Indizes um 35 % und einer Verbesserung der Leseleistung um 5 %. <\/p>\n
Im Befehl \u201egit pack-objects\u201c wurde die Option \u201e\u2014path-walk\u201c hinzugef\u00fcgt, die eine neue Methode zur Erfassung von Informationen \u00fcber Objekte beim Repacken von Pack-Dateien einf\u00fchrt. Anstatt die Objekte in der Reihenfolge der Revisionen zu durchlaufen, werden beim Einsatz des Modus \u201e\u2014path-walk\u201c die Objekte \u00fcber den Durchlauf von Dateipfaden aufgelistet, was es erm\u00f6glicht, alle Objekte mit demselben Dateipfad gleichzeitig zu packen. Diese Herangehensweise erm\u00f6glicht es, die Heuristik, die Hashing zur Bestimmung der Beziehung zwischen einem Objekt und seinem Dateipfad verwendet, auszuschlie\u00dfen und das Sortieren von Objekten vor dem Packen zu vermeiden. Bei Verwendung des Modus \u201e\u2014path-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 Arbeitsverzeichnisses und der Indizes im Repository, erstellt mit dem Befehl \u201egit stash\u201c, wurde definiert. Das neue Format erm\u00f6glicht es, die gespeicherten \u00c4nderungen (Stash-Eintr\u00e4ge) als eine Folge von Commits zu kodieren. F\u00fcr den Import und Export wurden 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 durchzuf\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 «git cat-file», der den Inhalt von angegebenen Objekten anzeigt, wurde die M\u00f6glichkeit implementiert, Informationen \u00fcber fehlende Objekte (zum Beispiel aufgrund von Besch\u00e4digungen im Repository) und Submodule anzuzeigen, wenn die Optionen «—batch» und «—batch-check» verwendet werden. Fr\u00fcher gab der Befehl «git cat-file —batch-check» beim Angabe des Pfads zu einem Submodul «missing» aus; jetzt wird die Objekt-ID angezeigt.\n
Im Befehl «git log» wurden Optimierungen auf Basis von Bloom-Filtern implementiert, um die Suche in der \u00c4nderungshistorie bei Angabe von Filtern mit mehreren Dateipfaden zu beschleunigen, beispielsweise «git log — path\/to\/a path\/to\/b».\n
Die Befehle «git switch» und «git restore» wurden stabilisiert, die seit 2019 als experimentell betrachtet wurden. Die Befehle werden als moderne \u00c4quivalente von «git checkout» pr\u00e4sentiert, die solche wenig zusammenh\u00e4ngenden Funktionen dieses Befehls wie das Wechseln und Erstellen von Branches sowie das Wiederherstellen von Dateien im Arbeitsverzeichnis trennen.\n
Der Befehl «git whatchanged», der \u00e4quivalent zu «git log —raw» ist, wurde als veraltet erkl\u00e4rt und ist geplant zu werden, in der Git-Version 3.0 entfernt zu werden.\n
Im Befehl «git for-each-ref» wurde die Option «—start-after» hinzugef\u00fcgt, die in Verbindung mit der Option «—count» verwendet werden kann, um eine paginierte Ausgabe zu organisieren.\n
In den Befehlen «git merge» und «git pull» wurde die Option «—compact-summary» hinzugef\u00fcgt, um anstelle des diffstat-Formats ein kompaktes Format der Zusammenfassung von \u00c4nderungen zu verwenden.\n
In der Git-Codebasis ist die Verwendung des Schl\u00fcsselworts «bool», das im C99-Standard eingef\u00fchrt wurde, erlaubt. Au\u00dferdem werden einige Funktionen von C99 dokumentiert, die experimentell in Git verwendet werden (zum Beispiel ist geplant, Mitte 2026 die Verwendung von Konstruktionen wie «(struct foo){ .member = value };» zuzulassen). Ein Kompiler, der C99 unterst\u00fctzt, ist seit 2021 f\u00fcr Git erforderlich, jedoch werden Funktionen der C99-Spezifikation \u00e4u\u00dferst vorsichtig implementiert, um die Kompatibilit\u00e4t mit Compilern, die diesen Standard nur teilweise unterst\u00fctzen, zu wahren.\n
Die Regeln f\u00fcr die Annahme von Patches wurden ge\u00e4ndert, um die Einreichung von Patches unter einem Pseudonym zuzulassen, nicht nur unter dem echten Namen des Entwicklers. Diese \u00c4nderung entspricht den Regeln f\u00fcr die Annahme von Patches im Linux-Kernel.\n
Die Liste der inkompatiblen \u00c4nderungen wurde aktualisiert, die in der Git-Version 3.0 angewendet werden. Zu den wichtigsten \u00c4nderungen in der bevorstehenden Ver\u00f6ffentlichung von Git 3.0 geh\u00f6rt der standardm\u00e4\u00dfige Wechsel zu Objekt-IDs, die auf dem SHA-256-Hashalgorithmus basieren, bei der Initialisierung neuer Repositories, sowie die Verwendung des Formats \u201ereftable\u201c zur Speicherung von Verweisen auf Zweige und Tags im Repository (unter Verwendung des Blockspeichers aus dem JGit-Projekt, das f\u00fcr die Speicherung einer sehr gro\u00dfen Anzahl von Referenzen optimiert ist). <\/ul>\n