{"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\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","title":{"rendered":"Version des Quellcodeverwaltungssystems Git 2.52.","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 f\u00fcr nichtlineare Entwicklungen, die auf Verzweigungen und Zusammenf\u00fchrungen von Zweigen basieren. Um die Integrit\u00e4t der Geschichte zu gew\u00e4hrleisten und Resistenz gegen \"nachtr\u00e4gliche\" \u00c4nderungen zu bieten, wird das gesamte fr\u00fchere Geschichtswesen in jedem Commit implizit gehasht, und die digitalen Signaturen der Entwickler f\u00fcr einzelne Tags und Commits werden verwendet. Der Git-Code wird unter der GPLv2+-Lizenz verbreitet. <\/p>\n
Im Vergleich zur vorherigen Version wurden 637 \u00c4nderungen in die neue Version aufgenommen, die mit Beteiligung von 94 Entwicklern (33 davon nahmen erstmals an der Entwicklung von Git teil) vorbereitet wurden. Die wichtigsten Neuerungen (1, 2, 3): <\/p>\n
\n
Der Befehl \"git last-modified\" wurde hinzugef\u00fcgt, um eine Liste der Dateien in der angegebenen Revision und 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
Der Befehl \"git repo\" wurde hinzugef\u00fcgt, um Aktionen auszuf\u00fchren, die mit dem Abrufen von Informationen aus dem Repository verbunden sind. Es wurden zwei Unterbefehle vorgeschlagen \u2014 \"git repo info\" und \"git repo structure\", die Informationen \u00fcber die Repository-Einstellungen und Details zur Repository-Struktur ausgeben (zum Beispiel kann die Anzahl der Verweise und Objekte im Repository ermittelt werden). $ git repo info object.format references.format object.format=sha1 references.format=reftable $ git repo structure | Repository-Struktur | Wert | | \u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014 | \u2014\u2014\u2014\u2014 | | * Verweise | | | * Anzahl | 1983 | | * Zweige | 4 | | * Tags | 1125 | | * Remotes | 854 | | * Sonstiges | 0 | | | | | * Erreichbare Objekte | | | * Anzahl | 518955 | | * Commits | 77469 | | * B\u00e4ume | 188865 | | * Blobs | 251631 | | * Tags | 990 |\n
Dem Befehl \"git refs\" wurden drei Unterbefehle hinzugef\u00fcgt, die disparate und \u00fcberlappende Low-Level-Operationen an Referenzen (git for-each-ref, git show-ref, git update-ref und git pack-refs) vereinheitlichen:\n
\n
\"git refs optimize\" \u2014 die Optimierung des Backend-Speichers 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\" \u2014 \u00fcberpr\u00fcft die Existenz einer Referenz (analog zu \"git show-ref --exists\"). <\/ul>\n
Das Format f\u00fcr den Export oder Import von Commit-Historien wurde um die M\u00f6glichkeit zur Verwendung von kryptografischen Signaturen erweitert, die sowohl als Objektidentifikatoren auf der Basis des SHA-1-Algorithmus als auch auf der Basis von SHA-256 fungieren. Im Befehl \u201egit fast-import\u201c wurde die Unterst\u00fctzung f\u00fcr die Verarbeitung von signierten Tags analog zu signierten Commits implementiert. Es wurden die Optionen \u201e--signed-commits=\u201c und \u201e--signed-tags=\u201c 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
Im Befehl \u201egit maintenance\u201c wurde die Unterst\u00fctzung f\u00fcr die neue Strategie \u201egeometric\u201c hinzugef\u00fcgt (\u201egit config set maintenance.strategy geometric\u201c), die die Wartungszeiten gro\u00dfer Monorepositories verk\u00fcrzt. Im Vergleich zur zuvor verf\u00fcgbaren Strategie, die die Logik des Befehls \u201egit gc\u201c verwendet, vermeidet die neue Strategie das Repacken aller Objekte und schlie\u00dft \u00fcberm\u00e4\u00dfig ressourcenintensive Operationen wie das Zusammenf\u00fchren aller Pack-Dateien aus (sofern m\u00f6glich, erfolgt die Zusammenf\u00fchrung schrittweise und ohne die Bereinigung gel\u00f6schter Objekte).\n
Der Befehl \u201egit sparse-checkout clean\u201c wurde hinzugef\u00fcgt, um die Wiederherstellung des Zustands des Arbeitsverzeichnisses zu erleichtern, indem Dateien entfernt werden, die nicht der neuen Definition des Sparse-Checkout entsprechen und daher nicht in der lokalen Kopie vorhanden sein sollten gem\u00e4\u00df den aktuellen Sparse-Checkout-Einstellungen.\n
Um die Codebasis von Komplexit\u00e4ten zu befreien und die Wartung zu erleichtern, wurde ein Refactoring durchgef\u00fchrt, um die Verwendung der globalen Variablen the_repository zu reduzieren.\n
Die Anwendung von Bloom-Filtern, einer probabilistischen Struktur zur \u00dcberpr\u00fcfung des Vorhandenseins in einer Menge, wurde erweitert. Diese Filter k\u00f6nnen f\u00e4lschlicherweise angeben, dass ein Element fehlt, aber weisen sicher darauf hin, dass ein bestehendes Element vorhanden ist. Bloom-Filter werden nun verwendet, um die Suche in der \u00c4nderungsverlaufshistorie zu beschleunigen, insbesondere bei Angabe von Masken in Dateipfaden, z. B. \u201efoo\/bar\/*\/baz\u201c.\n
Die Leistung des Befehls \u201egit describe\u201c wurde um 30 % verbessert, dank der Verwendung einer Priorit\u00e4tenwarteschlange. In \u201egit remote rename\u201c wurden die Umbenennungsoperationen beschleunigt. In \u201egit ls-files\u201c wurde die Anwendung von Indizes erweitert. Die Ausf\u00fchrung des Befehls \u201egit log -L\u201c wurde sp\u00fcrbar beschleunigt, indem \u00fcberfl\u00fcssige dreistufige Vergleiche bei der Verarbeitung von Merge-Commits ausgeschlossen wurden. Es wurden Optimierungen in der Bibliothek xdiff vorgenommen.\n
Es wurde die optionale M\u00f6glichkeit bereitgestellt, Implementierungen bestimmter interner Funktionen in der Programmiersprache Rust zu verwenden, wie z.B. das Codieren und Dekodieren von ganzzahligen Werten variabler L\u00e4nge. Standardm\u00e4\u00dfig wird kein Rust-Code verwendet, und um ihn zu aktivieren, muss das Build-Flag WITH_RUST angegeben werden. In Zukunft wird erwartet, dass bedeutendere interne Komponenten von Git auf Rust umgestellt werden, und dass Rust zu den verpflichtenden Build-Abh\u00e4ngigkeiten in Git 3.0 geh\u00f6rt.\n
Die Liste der inkompatiblen \u00c4nderungen, die im Branch Git 3.0 umgesetzt werden, wurde aktualisiert. In Git 3.0 soll die Einstellung init.defaultBranch standardm\u00e4\u00dfig auf den Wert \u201emain\u201c ge\u00e4ndert werden, d.h. in Repositories, die mit dem Befehl \u201egit init\u201c erstellt werden, wird der Standardbranch \u201emain\u201c und nicht \u201emaster\u201c genannt. Es wird auch auf den standardm\u00e4\u00dfigen Umstieg auf Objekt-IDs basierend auf dem Hashing-Algorithmus SHA-256 bei der Initialisierung neuer Repositories hingewiesen. Um die Portabilit\u00e4t zwischen Repositories mit Objekt-IDs auf Basis von SHA-1- und SHA-256-Hashes zu erleichtern, wird die M\u00f6glichkeit geschaffen, in einem Repository mit einem Hashing-Algorithmus Push- und Pull-Operationen aus einem Repository durchzuf\u00fchren, das einen anderen Hashing-Algorithmus verwendet. <\/ul>\n