{"id":103816,"date":"2022-04-19T15:36:47","date_gmt":"2022-04-19T13:36:49","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-36"},"modified":"2022-04-19T15:36:47","modified_gmt":"2022-04-19T13:36:49","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-36","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-36","title":{"rendered":"Release der Versionierungssystem Git 2.36","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach drei Monaten Entwicklung wurde die Version 2.36 des verteilten Systems zur Verwaltung von Quelltexten Git ver\u00f6ffentlicht. Git geh\u00f6rt zu den beliebtesten, zuverl\u00e4ssigsten und leistungsst\u00e4rksten Versionsverwaltungssystemen und bietet flexible M\u00f6glichkeiten der nichtlinearen Entwicklung basierend auf Branching und Merging. Um die Integrit\u00e4t der Historie und die Widerstandsf\u00e4higkeit gegen r\u00fcckwirkende \u00c4nderungen zu gew\u00e4hrleisten, erfolgt eine implizite Hash-Berechnung der gesamten vorherigen Historie in jedem Commit. Auch die digitale Signatur einzelner Tags und Commits durch die Entwickler ist m\u00f6glich. <\/p>\n
Im Vergleich zur vorherigen Version wurden in dieser neuen Version 717 \u00c4nderungen aufgenommen, die mit der Mitarbeit von 96 Entwicklern vorbereitet wurden, von denen 26 erstmals an der Entwicklung teilnahmen. Die wichtigsten Neuerungen: <\/p>\n
\n
In den Befehlen «git log» und «git show» wurde die Option «—remerge-diff» hinzugef\u00fcgt, mit der die Unterschiede zwischen dem allgemeinen Merge-Ergebnis und den tats\u00e4chlichen Daten, die im Commit nach der Ausf\u00fchrung des «merge»-Befehls widergespiegelt werden, angezeigt werden k\u00f6nnen. Dies erm\u00f6glicht eine anschauliche Bewertung der \u00c4nderungen, die durch die Konfliktl\u00f6sung beim Merging vorgenommen wurden. Der regul\u00e4re Befehl «git show» separiert verschiedene Konfliktl\u00f6sungsans\u00e4tze mit Einr\u00fcckungen, was das Verst\u00e4ndnis der \u00c4nderungen erschwert. Zum Beispiel zeigen die Zeilen «+\/-» ohne Einr\u00fcckung auf dem Screenshot unten die letzte Konfliktl\u00f6sung, die mit der Umbenennung im ersten Branch von sha1 zu oid im Kommentar verbunden ist, w\u00e4hrend «+\/-» mit Einr\u00fcckung \u2014 die urspr\u00fcngliche Konfliktl\u00f6sung darstellt, die durch das Hinzuf\u00fcgen eines weiteren Arguments in der Funktion dwim_ref() im zweiten Branch verursacht wurde.
<\/center>\n
Bei Verwendung der Option «—remerge-diff» werden die Unterschiede zwischen den Konfliktl\u00f6sungen nicht f\u00fcr jeden Eltern-Branch separat angezeigt, sondern stattdessen die allgemeinen Unterschiede zwischen der Datei mit Merge-Konflikten und der Datei, in der die Konflikte gel\u00f6st wurden.
<\/center> <\/p>\n
Die Flexibilit\u00e4t bei der Konfiguration des Verhaltens beim Zur\u00fccksetzen von Festplattencaches durch den Aufruf der Funktion fsync() wurde erh\u00f6ht. Der zuvor verf\u00fcgbare Parameter core.fsyncObjectFiles wurde in zwei Konfigurationsvariablen, core.fsync und core.fsyncMethod, unterteilt, die es erm\u00f6glichen, fsync nicht nur auf Objektdateien (.git\/objects), sondern auch auf andere Git-Strukturen wie Referenzen (.git\/refs), Reflog und Packdateien anzuwenden.\n
\u00dcber die Variable core.fsync kann eine Liste interner Git-Strukturen angegeben werden, f\u00fcr die nach einem Schreibvorgang zus\u00e4tzlich fsync aufgerufen wird. Die Variable core.fsyncMethod erm\u00f6glicht die Auswahl der Methode zum Zur\u00fccksetzen des Caches; beispielsweise kann fsync f\u00fcr den entsprechenden Systemaufruf ausgew\u00e4hlt oder writeout-only zur Verwendung von verz\u00f6gertem Schreiben (pagecache writeback) angegeben werden. <\/p>\n
Um Schwachstellen zu sch\u00fctzen, die durch die Manipulation von .git-Verzeichnissen anderer Benutzer in gemeinsam genutzten Bereichen entstehen, wurde die \u00dcberpr\u00fcfung des Repository-Besitzers verst\u00e4rkt. Das Ausf\u00fchren von Git-Befehlen ist jetzt nur noch in den eigenen Verzeichnissen «.git» erlaubt. Wenn das Verzeichnis des Repositories einem anderen Benutzer geh\u00f6rt, wird standardm\u00e4\u00dfig ein Fehler ausgegeben. Dieses Verhalten kann durch die Einstellung safe.directory deaktiviert werden.\n
Dem Befehl «git cat-file», der zum Anzeigen des Quellinhalts von Git-Objekten gedacht ist, wurde die Option «—batch-command» hinzugef\u00fcgt, die die zuvor verf\u00fcgbaren Befehle «—batch» und «—batch-check» erg\u00e4nzt. Damit kann der Ausgabetyp durch Angabe von «contents <Objekt>» f\u00fcr die Ausgabe des Inhalts oder «info <Objekt>» f\u00fcr die Ausgabe von Objektinformationen adaptiv gew\u00e4hlt werden. Zus\u00e4tzlich wird der Befehl «flush» zur R\u00fccksetzung des Ausgabepuffers unterst\u00fctzt.\n
Im Befehl git ls-tree<\/code> wurde die Option --oid-only<\/code> (--object-only<\/code>) hinzugef\u00fcgt, die analog zu --name-only<\/code> nur die Objekt-IDs ausgibt, um die Verwendung in Skripten zu erleichtern. Au\u00dferdem wurde die Option --format<\/code> implementiert, die es erm\u00f6glicht, ein eigenes Ausgabeformat zu definieren, indem Informationen \u00fcber Modus, Typ, Name und Gr\u00f6\u00dfe kombiniert werden.\n
Im Befehl git bisect run<\/code> wurde die Erkennung der Ausf\u00fchrbarkeit des Skripts implementiert. Tritt ein Fehler auf, wird dieser nun mit dem Code 126 oder 127 angezeigt (fr\u00fcher wurden alle Revisionen als problematisch markiert, wenn das Skript nicht gestartet werden konnte).\n
Im Befehl git fetch<\/code> wurde die Option --refetch<\/code> hinzugef\u00fcgt, um alle Objekte zu extrahieren, ohne die andere Seite \u00fcber den bereits vorhandenen Inhalt im lokalen System zu informieren. Dieses Verhalten kann n\u00fctzlich sein, um den Zustand nach einem Ausfall wiederherzustellen, wenn keine Sicherheit \u00fcber die Integrit\u00e4t der lokalen Daten besteht.\n
Bei den Befehlen git update-index<\/span>, git checkout-index<\/span>, git read-tree<\/span> und git clean<\/span> wurde die Unterst\u00fctzung f\u00fcr partielle Indizes (sparse index) hinzugef\u00fcgt, die die Performance steigern und Platz in Repositories sparen, in denen partielle Klonvorg\u00e4nge (sparse-checkout) durchgef\u00fchrt werden.\n
Das Verhalten des Befehls git clone --filter=... --recurse-submodules<\/span> wurde ge\u00e4ndert, sodass nun eine partielle Klonung von Submodulen erfolgt (zuvor wurde der Filter nur auf den Hauptinhalt angewendet, w\u00e4hrend Submodule vollst\u00e4ndig ohne Ber\u00fccksichtigung des Filters geklont wurden).\n
Im Befehl git bundle<\/span> wurde die Unterst\u00fctzung f\u00fcr das Angeben von Filtern hinzugef\u00fcgt, um Inhalte selektiv \u00e4hnlich wie bei partiellem Klonen bereitzustellen.\n
Im Befehl git branch<\/span> wurde die Option --recurse-submodules<\/span> f\u00fcr das rekursive Durchlaufen von Submodulen hinzugef\u00fcgt.\n
F\u00fcr die Sprache Kotlin wurde ein neuer Userdiff-Handler vorgeschlagen. <\/ul>\n
![\"Release](\"\/wp-content\/uploads\/2022\/04\/75651aa0f36ad2b5896991a675754b1f.jpg\")
<\/center>\n![\"Release](\"\/wp-content\/uploads\/2022\/04\/903ff119e179781b6e0de91205765a6a.jpg\")
<\/center> <\/p>\n