{"id":106023,"date":"2022-12-13T15:36:42","date_gmt":"2022-12-13T13:36:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-39"},"modified":"2022-12-13T15:36:42","modified_gmt":"2022-12-13T13:36:42","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-39","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-39","title":{"rendered":"Ver\u00f6ffentlichung des Versionskontrollsystems Git 2.39","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach zwei Monaten Entwicklung wurde die Version 2.39 des verteilten Versionsverwaltungssystems Git ver\u00f6ffentlicht. Git ist eines der beliebtesten, zuverl\u00e4ssigsten und leistungsst\u00e4rksten Versionskontrollsysteme, das flexible, nichtlineare Entwicklungswerkzeuge bietet, die auf dem Verzweigen und Zusammenf\u00fchren von Branches basieren. Um die Integrit\u00e4t der Historie und die Widerstandsf\u00e4higkeit gegen\u00fcber nachtr\u00e4glichen \u00c4nderungen zu gew\u00e4hrleisten, wird eine implizite Hash-Pr\u00fcfung der gesamten vorherigen Historie in jedem Commit verwendet; au\u00dferdem ist eine Verifizierung durch digitale Signaturen der Entwickler f\u00fcr bestimmte Tags und Commits m\u00f6glich. <\/p>\n
Im Vergleich zur vorherigen Version wurden in die neue Version 483 \u00c4nderungen aufgenommen, die mit Beteiligung von 86 Entwicklern vorbereitet wurden, von denen 31 zum ersten Mal an der Entwicklung teilnahmen. Die wichtigsten Neuerungen: <\/p>\n
\n
Das Team von \u201egit shortlog\u201c, das darauf ausgelegt ist, Statistiken aus der \u00c4nderungsverlaufshistorie anzuzeigen, hat die Option \u201e\u2014group\u201c hinzugef\u00fcgt, um Commits nach beliebigen Feldern zu gruppieren, die nicht auf den Autor oder Committer beschr\u00e4nkt sind. Zum Beispiel kann der folgende Befehl verwendet werden, um eine Liste der Entwickler zusammen mit Informationen \u00fcber die Anzahl der \u00c4nderungen, einschlie\u00dflich der in dem Feld \u201eCo-authored-by\u201c erw\u00e4hnten Mitautoren, anzuzeigen: git shortlog -ns \u2014group=author \u2014group=trailer:co-authored-by.\n
Der shortlog-Ausgabe kann durch Formatierungsspezifizierer aggregiert werden, und die Option \u201e\u2014group\u201c erleichtert erheblich die Erstellung komplexer Berichte und erm\u00f6glicht es, zus\u00e4tzliche Sortierbefehle zu vermeiden. Zum Beispiel, um einen Bericht zu erstellen, der zeigt, wie viele Commits f\u00fcr eine bestimmte Version in jedem Monat akzeptiert wurden, k\u00f6nnen Sie angeben: git shortlog v2.38.0.. \u2014date='format:%Y-%m' \u2014group='' -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Fr\u00fcher h\u00e4tte eine \u00e4hnliche Operation die Nutzung der Tools sort und uniq erfordert: git log v2.38.0.. \u2014date='format:%Y-%m' \u2014format='' | sort | uniq -c <\/p>\n
Die M\u00f6glichkeiten des Mechanismus \u201ecruft packs\u201c wurden erweitert, der zum Packen von unerreichbaren Objekten verwendet wird, auf die im Repository keine Verweise existieren (keine Branches oder Tags verweisen darauf). Unerreichbare Objekte werden vom Garbage Collector entfernt, verbleiben jedoch f\u00fcr eine bestimmte Zeit im Repository, um Rennbedingungen auszuschlie\u00dfen. Der Mechanismus \u201ecruft packs\u201c erm\u00f6glicht es, alle unerreichbaren Objekte in einer Pack-Datei zu speichern und die Zeitstempel jedes Objekts in einer separaten Tabelle zu erfassen, die in einer separaten Datei mit der Erweiterung \u201e.mtimes\u201c gespeichert wird, um eine \u00dcberschneidung mit der allgemeinen \u00c4nderungszeit zu vermeiden.\n
Die Zeit, die unerreichbare Objekte im Repository verbleiben, bevor sie tats\u00e4chlich gel\u00f6scht werden, wird durch die Option \u201e--prune=\u201c bestimmt. Obwohl die Verz\u00f6gerung vor der L\u00f6schung eine recht effektive und praktikable Methode darstellt, um zu verhindern, dass das Repository aufgrund von Rennbedingungen besch\u00e4digt wird, ist sie nicht zu 100 % zuverl\u00e4ssig. Um die Wiederherstellung eines besch\u00e4digten Repositories zu erleichtern, wird in der neuen Version die M\u00f6glichkeit zur Speicherung fehlender Objekte bereitgestellt. Dazu wurde der Befehl \u201egit repack\u201c um die Option \u201e--expire-to\u201c erweitert, die es erm\u00f6glicht, eine Datei f\u00fcr die Erstellung einer externen Kopie aller gel\u00f6schten Objekte anzugeben. Beispielsweise kann zur Speicherung unerreichbarer Objekte in der Datei backup.git, die sich in den letzten 5 Minuten nicht ge\u00e4ndert haben, der Befehl verwendet werden: git repack --cruft --cruft-expiration=5.minutes.ago -d --expire-to=..\/backup.git. <\/p>\n
Die Geschwindigkeit der Operation \u201egit grep --cached\u201c wurde bei der Suche in Bereichen, in denen das partielle Klonen (sparse-checkout) angewendet wird und f\u00fcr die partielle Indizes (sparse index) vorhanden sind, erheblich erh\u00f6ht (um bis zu 70 %). Fr\u00fcher erfolgte bei Angabe der Option \u201e--cached\u201c zuerst die Suche im normalen Index und dann in den teilweisen, was zu sp\u00fcrbaren Verz\u00f6gerungen bei der Suche in gro\u00dfen Repositories f\u00fchrte.\n