{"id":105249,"date":"2022-10-04T15:36:37","date_gmt":"2022-10-04T13:36:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-38"},"modified":"2022-10-04T15:36:37","modified_gmt":"2022-10-04T13:36:37","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-38","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-38","title":{"rendered":"Release des Versionsverwaltungssystems Git 2.38","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Version 2.38 des verteilten Quelltextverwaltungssystems Git wurde ver\u00f6ffentlicht. Git ist eines der beliebtesten, zuverl\u00e4ssigsten und leistungsf\u00e4higsten Versionskontrollsysteme, das flexible Mittel f\u00fcr nichtlineare Entwicklung basierend auf Branching und Merging bietet. Um die Integrit\u00e4t der Historie und die Widerstandsf\u00e4higkeit gegen nachtr\u00e4gliche \u00c4nderungen zu gew\u00e4hrleisten, wird eine implizite Hash-\u00dcberpr\u00fcfung der gesamten vorherigen Historie in jedem Commit verwendet. Au\u00dferdem ist es m\u00f6glich, digitale Signaturen von Entwicklern f\u00fcr einzelne Tags und Commits zu verifizieren. <\/p>\n
Im Vergleich zur vorherigen Version wurden 699 \u00c4nderungen in die neue Version aufgenommen, die von 92 Entwicklern vorbereitet wurden, von denen 24 zum ersten Mal an der Entwicklung teilnahmen. Zu den wichtigsten Neuerungen z\u00e4hlen: <\/p>\n
\n
In die Grundausstattung wurde das von Microsoft entwickelte Tool \u201escalar\u201c aufgenommen, das zur Verwaltung gro\u00dfer Repositories dient. Das Tool wurde urspr\u00fcnglich in C# geschrieben, jedoch wurde eine \u00fcberarbeitete Version in C in Git integriert. Das neue Tool unterscheidet sich von den Git-Befehlen durch standardm\u00e4\u00dfig aktivierte zus\u00e4tzliche Funktionen und Einstellungen, die die Leistung bei der Arbeit mit sehr gro\u00dfen Repositories beeinflussen. Zum Beispiel wird bei der Verwendung von scalar Folgendes angewendet:\n
\n
Teilweises Klonen f\u00fcr die Arbeit mit einer unvollst\u00e4ndigen Kopie des Repositories.\n
Ein integrierter Mechanismus zur \u00dcberwachung von \u00c4nderungen im Dateisystem (FSMonitor), der es erm\u00f6glicht, auf eine vollst\u00e4ndige Durchsuchung des Arbeitsverzeichnisses zu verzichten.\n
Indizes, die Objekte in verschiedenen Pack-Dateien abdecken (Multi-Pack).\n
Commit-Graph-Dateien mit einem Index des Commit-Graphs, der zur Optimierung des Zugriffs auf Informationen \u00fcber Commits verwendet wird.\n
Hintergrundarbeiten zur Aufrechterhaltung der optimalen Struktur des Repositories im Hintergrund, ohne die interaktive Sitzung zu blockieren (jede Stunde wird eine Aufgabe zur proaktiven \u0437\u0430\u0433\u0440\u0443\u0437\u043a\u0435 neuer Objekte aus dem entfernten Repository sowie zur Aktualisierung der Commit-Grafdatei ausgef\u00fchrt, w\u00e4hrend jede Nacht ein Verpackungsprozess f\u00fcr das Repository startet).\n
Der Modus \u201esparseCheckoutCone\u201c, der zul\u00e4ssige Muster bei teilweisem Klonen einschr\u00e4nkt. <\/ul>\n
Das Kommando «git rebase» wurde um die Option «—update-refs» erweitert, die abh\u00e4ngige Branches aktualisiert, die mit den verschobenen Branches in Konflikt stehen, sodass kein manuelles Checkout jeder abh\u00e4ngigen Branch erforderlich ist, um auf den gew\u00fcnschten Commit zu wechseln.\n
Die Kompatibilit\u00e4t des Befehls «git rm» mit partiellen Indizes wurde sichergestellt.\n
Das Verhalten des Befehls «git mv A B» wurde verbessert, wenn eine Datei aus dem Arbeitsverzeichnis mit partiellen Indizes im «cone»-Modus in ein externes Verzeichnis verschoben wird, auf das dieser Modus nicht angewendet wird.\n
Das Format der Bitmap-Dateien wurde f\u00fcr die Arbeit mit gro\u00dfen Repositories optimiert \u2013 eine optionale Indextabelle mit einer Liste ausgew\u00e4hlter Commits und deren Offsets wurde hinzugef\u00fcgt.\n
Im Befehl «git merge-tree» wurde ein neuer Modus implementiert, bei dem auf Basis von zwei angegebenen Commits ein Baum mit dem Ergebnis der Zusammenf\u00fchrung berechnet wird, als ob die Geschichte dieser Commits kombiniert worden w\u00e4re.\n
Die Einstellung \u201esafe.barerepository\u201c wurde hinzugef\u00fcgt, um die M\u00f6glichkeit zu steuern, bare-Repositories (Repositories ohne Arbeitsverzeichnis) innerhalb anderer Git-Repositories zu platzieren. Wenn der Wert auf \u201eexplicit\u201c gesetzt ist, werden nur bare-Repositories im obersten Verzeichnis erlaubt. Um bare-Repositories in Unterverzeichnissen zuzulassen, sollte der Wert auf \u201eall\u201c gesetzt werden.\n
Dem Befehl \u201egit grep\u201c wurde die Option \u201e-m\u201c (\u201e--max-count\u201c) hinzugef\u00fcgt, \u00e4hnlich der gleichnamigen Option in GNU grep, die es erm\u00f6glicht, die Anzahl der ausgegebenen \u00dcbereinstimmungen zu begrenzen.\n
Im Befehl \u201els-files\u201c wurde die Option \u201e--format\u201c implementiert, um die ausgegebenen Felder anzupassen (zum Beispiel kann das Objektname, Modi usw. ausgegeben werden).\n
In \u201egit cat-file\u201c wurde bei der Anzeige des Inhalts von Objekten die M\u00f6glichkeit umgesetzt, die Bindungen der Autoren an E-Mails, die in der Datei mailmap festgelegt sind, zu ber\u00fccksichtigen. <\/ul>\n