{"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\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-36","title":{"rendered":"Ver\u00f6ffentlichung des Quellcode-Management-Systems Git 2.36.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach drei Monaten Entwicklung wurde die Version 2.36 des verteilten Versionskontrollsystems Git ver\u00f6ffentlicht. Git ist eines der beliebtesten, zuverl\u00e4ssigsten und leistungsf\u00e4higsten Versionskontrollsysteme und bietet flexible Mittel f\u00fcr nicht-lineare Entwicklung, die auf Branching und Merging basieren. Um die Integrit\u00e4t der Historie und die Resistenz gegen r\u00fcckblickende \u00c4nderungen zu gew\u00e4hrleisten, wird das gesamte fr\u00fchere Geschichtshashing in jedem Commit implizit verwendet, und die digitale Signaturen der Entwickler f\u00fcr einzelne Tags und Commits sind ebenfalls m\u00f6glich. <\/p>\n
Im Vergleich zur vorherigen Version wurden in die neue Version 717 \u00c4nderungen aufgenommen, die mit Beteiligung von 96 Entwicklern erstellt wurden, von denen 26 zum ersten Mal an der Entwicklung teilnahmen. Die wichtigsten Neuerungen sind: <\/p>\n
\n
Zu den Befehlen \u201egit log\u201c und \u201egit show\u201c wurde die Option \u201e\u2014remerge-diff\u201c hinzugef\u00fcgt, die es erm\u00f6glicht, die Unterschiede zwischen dem gemeinsamen Merge-Ergebnis und den tats\u00e4chlichen Daten, die im Commit nach der Verarbeitung des \u201emerge\u201c-Befehls festgehalten sind, anzuzeigen, was eine anschauliche Bewertung der \u00c4nderungen erm\u00f6glicht, die durch die Konfliktl\u00f6sung beim Mergen vorgenommen wurden. Der normale \u201egit show\u201c-Befehl trennt verschiedene Konfliktl\u00f6sungen durch Einr\u00fcckung, was das Verst\u00e4ndnis der \u00c4nderungen erschwert. Zum Beispiel zeigt die folgende Abbildung die Zeilen \u201e+\/-\u201c ohne Einr\u00fcckung, die die letzte Konfliktl\u00f6sung betrifft, die mit der Umbenennung im ersten Branch von sha1 zu oid im Kommentar verbunden ist, w\u00e4hrend \u201e+\/-\u201c mit Einr\u00fcckung die urspr\u00fcngliche Konfliktl\u00f6sung ist, die durch das Hinzuf\u00fcgen eines zus\u00e4tzlichen Arguments in der Funktion dwim_ref() im zweiten Branch verursacht wurde.
<\/center>\n
Bei Verwendung der Option \u201e\u2014remerge-diff\u201c werden die Unterschiede zwischen den Konfliktl\u00f6sungen nicht f\u00fcr jeden \u00fcbergeordneten Branch getrennt angezeigt, sondern die allgemeinen Unterschiede zwischen der Datei mit Merge-Konflikten und der Datei, in der die Konflikte gel\u00f6st wurden, werden gezeigt.
<\/center> <\/p>\n
Die Flexibilit\u00e4t zur Anpassung des Verhaltens beim Zur\u00fccksetzen von Disk-Caches \u00fcber den Aufruf der Funktion fsync() wurde erh\u00f6ht. Der zuvor verf\u00fcgbare Parameter core.fsyncObjectFiles wurde in zwei Konfigurationsvariablen core.fsync und core.fsyncMethod aufgeteilt, die es erm\u00f6glichen, fsync nicht nur auf Objektdaten (.git\/objects) anzuwenden, sondern auch auf andere Git-Strukturen wie Referenzen (.git\/refs), Reflog und Pack-Dateien.\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 Leeren des Caches; zum Beispiel kann fsync gew\u00e4hlt werden, um den gleichnamigen Systemaufruf anzuwenden, oder writeout-only, um die verz\u00f6gerte Schreibweise (pagecache writeback) anzuwenden. <\/p>\n
Um vor Schwachstellen zu sch\u00fctzen, die durch andere Benutzer manipulierte .git-Verzeichnisse in gemeinsam genutzten Bereichen ausnutzen, wurde die \u00dcberpr\u00fcfung des Repository-Eigent\u00fcmers verst\u00e4rkt. Das Ausf\u00fchren beliebiger Git-Befehle ist jetzt nur in den eigenen \u201e.git\u201c-Verzeichnissen zul\u00e4ssig. Wenn das Verzeichnis mit dem Repository einem anderen Benutzer geh\u00f6rt, wird standardm\u00e4\u00dfig ein Fehler ausgegeben. Dieses Verhalten kann durch die Einstellung safe.directory deaktiviert werden.\n
Im Befehl «git cat-file», der zum Ausgeben des Rohinhalts von Git-Objekten dient, wurde die Option «—batch-command» hinzugef\u00fcgt, die die zuvor verf\u00fcgbaren Befehle «—batch» und «—batch-check» um die M\u00f6glichkeit des adaptiven Typerausschnitts durch die Angabe «contents <Objekt>» zum Ausgeben des Inhalts oder «info <Objekt>» zum Ausgeben von Informationen \u00fcber das Objekt erg\u00e4nzt. Zus\u00e4tzlich wird der Befehl «flush» zur leeren Ausgabeauff\u00fcllung unterst\u00fctzt.\n
Im Befehl «git ls-tree», der zur Erstellung einer Liste des Inhalts eines Objektbaums dient, wurde die Option «—oid-only» («—object-only») hinzugef\u00fcgt, die analog zu «—name-only» nur die Objekt-IDs ausgibt, um das Aufrufen aus Skripten zu vereinfachen. Zudem wurde die Option «—format» implementiert, die es erlaubt, ein eigenes Ausgabeformat zu definieren, welches Informationen \u00fcber Modus, Typ, Name und Gr\u00f6\u00dfe kombiniert.\n
Im Befehl «git bisect run» wurde die Nichtausf\u00fchrung des ausf\u00fchrbaren Dateisignals f\u00fcr das Skript und die Ausgabe in diesem Fall von Fehlern mit den Codes 126 oder 127 realisiert (fr\u00fcher wurden alle Revisionen als problematisch markiert, wenn das Skript nicht ausgef\u00fchrt werden konnte).\n
Im Befehl «git fetch» wurde die Option «—refetch» 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 Gewissheit \u00fcber die Integrit\u00e4t der lokalen Daten besteht.\n
In den Befehlen «git update-index», «git checkout-index», «git read-tree» und «git clean» wurde die Unterst\u00fctzung f\u00fcr partielle Indizes (sparse index) hinzugef\u00fcgt, die die Leistung verbessern und Speicherplatz in Repositories sparen, in denen partielle Klonvorg\u00e4nge (sparse-checkout) ausgef\u00fchrt werden.\n
Das Verhalten des Befehls «git clone —filter=… —recurse-submodules» wurde ge\u00e4ndert, sodass nun ein partielles Klonen von Submodulen erfolgt (fr\u00fcher wurde bei der Durchf\u00fchrung solcher Befehle der Filter nur auf den Hauptinhalt angewendet, w\u00e4hrend Submodule vollst\u00e4ndig ohne Ber\u00fccksichtigung des Filters geklont wurden).\n
Im Befehl «git bundle» wurde die Unterst\u00fctzung zur Angabe von Filtern f\u00fcr das selektive Platzieren von Inhalten analog zu den Vorg\u00e4ngen des partiellen Klonens hinzugef\u00fcgt.\n
Im Befehl «git branch» wurde die Option «—recurse-submodules» f\u00fcr das rekursive Durchlaufen von Submodulen hinzugef\u00fcgt.\n
F\u00fcr die Sprache Kotlin wurde ein neuer Handler in userdiff vorgeschlagen. <\/ul>\n
![\"Ver\u00f6ffentlichung](\"\/wp-content\/uploads\/2022\/04\/75651aa0f36ad2b5896991a675754b1f.jpg\")
<\/center>\n![\"Ver\u00f6ffentlichung](\"\/wp-content\/uploads\/2022\/04\/903ff119e179781b6e0de91205765a6a.jpg\")
<\/center> <\/p>\n