{"id":148781,"date":"2025-11-18T23:12:24","date_gmt":"2025-11-18T21:12:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52"},"modified":"2025-11-18T23:12:24","modified_gmt":"2025-11-18T21:12:24","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","title":{"rendered":"Die neue Version des Versionsverwaltungssystems Git 2.52 ist erschienen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach drei Monaten Entwicklung wurde die Version 2.52 des verteilten Systems zur Verwaltung von Quelltexten Git ver\u00f6ffentlicht. Git zeichnet sich durch hohe Leistung aus und bietet Mittel zur nichtlinearen Entwicklung, die auf Verzweigung und Zusammenf\u00fchrung von Branches basieren. Um die Integrit\u00e4t der Geschichte und die Widerstandsf\u00e4higkeit gegen\u00fcber \"Backdating\"-\u00c4nderungen zu gew\u00e4hrleisten, wird die gesamte vorherige Geschichte in jedem Commit implizit gehasht, und digitale Signaturen der Entwickler f\u00fcr einzelne Tags und Commits werden erstellt. Der Git-Code wird unter der GPLv2+-Lizenz verteilt. <\/p>\n
Im Vergleich zur vorherigen Version wurden in die neue Version 637 \u00c4nderungen aufgenommen, die mit der Beteiligung von 94 Entwicklern vorbereitet wurden (33 nahmen erstmals an der Entwicklung von Git teil). Wichtige Neuerungen (1, 2, 3): <\/p>\n
\n
Der Befehl \u201egit last-modified\u201c wurde hinzugef\u00fcgt, um eine Liste der Dateien in der angegebenen Revision sowie der Commits anzuzeigen, \u00fcber die die letzten \u00c4nderungen an jeder dieser Dateien vorgenommen wurden. $ git last-modified HEAD b56f6dcd7b4c90192018e848d0810f091d092913 test.h 29330ae4b820147c98e723399e9438c8bee60a8a test1.c 573ad8917beb99dc643b6e7f5c117a294384a575 test2.c\n
Das Kommando «git repo» wurde hinzugef\u00fcgt, um Aktionen im Zusammenhang mit dem Abrufen von Informationen aus einem Repository auszuf\u00fchren. Zwei Unterbefehle wurden vorgeschlagen \u2014 «git repo info» und «git repo structure», die Informationen zu den Einstellungen des Repositories und zur Struktur des Repositories ausgeben (zum Beispiel kann die Anzahl der Referenzen und Objekte im Repository abgerufen werden). $ git repo info object.format references.format object.format=sha1 references.format=reftable $ git repo structure | Repository-Struktur | Wert | | ——————— | —— | | * Referenzen | | | * Anzahl | 1983 | | * Branches | 4 | | * Tags | 1125 | | * Remotes | 854 | | * Sonstige | 0 | | | | * Erreichbare Objekte | | | * Anzahl | 518955 | | * Commits | 77469 | | * B\u00e4ume | 188865 | | * Blobs | 251631 | | * Tags | 990 |\n
Drei Unterbefehle wurden zum Befehl «git refs» hinzugef\u00fcgt, die disparate und sich \u00fcberschneidende Low-Level-Operationen an Referenzen vereinheitlichen (git for-each-ref, git show-ref, git update-ref und git pack-refs):\n
\n
«git refs optimize» \u2014 Optimierung des Backends zur Speicherung von Referenzen (analog zu «git pack-refs»).\n
«git refs list» \u2014 Gibt eine Liste aller Referenzen aus (analog zu «git for-each-ref» oder «git show-ref»).\n
«git refs exists» — \u00dcberpr\u00fcfung der Existenz eines Verweises (entspricht «git show-ref —exists»). <\/ul>\n
Das Format f\u00fcr den Export oder Import von Commit-Historien wurde um die M\u00f6glichkeit erweitert, mit kryptografischen Signaturen zu arbeiten, die sowohl Objekt-IDs auf der Grundlage des SHA-1- als auch des SHA-256-Algorithmus verwenden. Der Befehl «git fast-import» unterst\u00fctzt nun die Verarbeitung von signierten Tags analog zu signierten Commits. Es wurden Optionen «—signed-commits=<Modus>» und «—signed-tags=<Modus>» hinzugef\u00fcgt, um die Verarbeitung von signierten Commits und Tags w\u00e4hrend des Imports zu steuern (der Modus kann die Werte verbatim, warn-verbatim, warn-stri, strip oder abort annehmen).\n
Der Befehl «git maintenance» unterst\u00fctzt jetzt eine neue Strategie «geometric» («git config set maintenance.strategy geometric»), die die Wartungszeit gro\u00dfer Monorepositories verk\u00fcrzt. Im Vergleich zur zuvor verf\u00fcgbaren Strategie, die die Logik des Befehls «git gc» verwendet, vermeidet die neue Strategie das Repacken aller Objekte und schlie\u00dft ressourcenintensive Operationen wie das Mischen aller Packdateien aus (soweit m\u00f6glich, erfolgt die Zusammenf\u00fchrung schrittweise und ohne Bereinigung von entfernten Objekten).\n
Das Kommando «git sparse-checkout clean» wurde hinzugef\u00fcgt, um die Wiederherstellung des Arbeitsverzeichnisses zu erleichtern, indem Dateien entfernt werden, die nicht der neuen Definition des Sparse-Checkouts entsprechen und die gem\u00e4\u00df den aktuellen Sparse-Checkout-Einstellungen nicht in der lokalen Kopie vorhanden sein sollten.\n
Um die Codebasis von Komplexit\u00e4t zu befreien und die Wartung zu vereinfachen, wurde ein Refactoring durchgef\u00fchrt, um die Verwendung der globalen Variable the_repository zu reduzieren.\n
Die Anwendung von Bloom-Filtern wurde erweitert, einer probabilistischen Struktur zur \u00dcberpr\u00fcfung von Mitgliedschaften in Mengen, die falsche Negative zul\u00e4sst, aber das \u00dcbersehen eines vorhandenen Elements ausschlie\u00dft. Bloom-Filter werden jetzt eingesetzt, um die Suche in der Historie bei Angabe von Masken in Dateipfaden, wie z.B. «foo\/bar\/*\/baz», zu beschleunigen.\n
Die Leistung des Kommandos «git describe» wurde um bis zu 30 % erh\u00f6ht, indem eine Priorit\u00e4tswarteschlange verwendet wird. In «git remote rename» wurden die Umbenennungsoperationen beschleunigt. In «git ls-files» wurde die Verwendung von Indizes erweitert. Die Ausf\u00fchrung des Kommandos «git log -L» wurde deutlich beschleunigt, indem \u00fcberfl\u00fcssige dreistufige Vergleiche bei der Verarbeitung von Merge-Commits ausgeschlossen wurden. Optimierungen wurden in die xdiff-Bibliothek eingef\u00fchrt.\n
Es wurde die optionale M\u00f6glichkeit eingef\u00fchrt, Implementierungen in der Programmiersprache Rust f\u00fcr einige interne Funktionen wie das Kodieren und Dekodieren von variablen ganzzahligen Werten zu verwenden. Standardm\u00e4\u00dfig wird der Rust-Code nicht verwendet, und um ihn zu aktivieren, muss das Build-Flag WITH_RUST angegeben werden. In Zukunft wird erwartet, dass eine \u00dcberarbeitung wichtiger interner Git-Komponenten in Rust erfolgt und Rust zu den erforderlichen Build-Abh\u00e4ngigkeiten in Git 3.0 hinzugef\u00fcgt wird.\n
Die Liste der inkompatiblen \u00c4nderungen, die in der Git 3.0-Version angewendet werden, wurde aktualisiert. In Git 3.0 wurde beschlossen, die Standardeinstellung f\u00fcr init.defaultBranch auf «main» zu \u00e4ndern. Das bedeutet, dass in Repositories, die mit dem Befehl «git init» erstellt werden, der Standardbranch «main» und nicht «master» hei\u00dfen wird. Es wird auch der \u00dcbergang zu object IDs basierend auf dem SHA-256-Hash-Algorithmus bei der Initialisierung neuer Repositories angesprochen. Um die Portabilit\u00e4t zwischen Repositories mit SHA-1- und SHA-256-Hash-ID zu erleichtern, wird die M\u00f6glichkeit bereitgestellt, in einem Repository mit einem Hash-Algorithmus Push- und Pull-Operationen von einem Repository durchzuf\u00fchren, das einen anderen Hash-Algorithmus verwendet. <\/ul>\n