{"id":118622,"date":"2024-07-30T09:43:00","date_gmt":"2024-07-30T07:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46"},"modified":"2024-07-30T09:43:00","modified_gmt":"2024-07-30T07:43:00","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46","title":{"rendered":"Ver\u00f6ffentlichung des Versionsverwaltungsprogramms Git 2.46","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach drei Monaten Entwicklung wurde die Version 2.46 des verteilten Versionskontrollsystems Git ver\u00f6ffentlicht. Git z\u00e4hlt zu den beliebtesten, zuverl\u00e4ssigsten und leistungsf\u00e4higsten Versionsverwaltungssystemen und bietet flexible Werkzeuge f\u00fcr nichtlineare Entwicklungen, die auf Branching und Merging basieren. Um die Integrit\u00e4t der Historie und die Widerstandsf\u00e4higkeit gegen\u00fcber \u00c4nderungen \"im Nachhinein\" zu gew\u00e4hrleisten, wird das implizite Hashing 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 verwenden. Der Git-Code wird unter der Lizenz GPLv2+ ver\u00f6ffentlicht. <\/p>\n
Im Vergleich zur vorherigen Version wurden in diese neue Version 746 \u00c4nderungen aufgenommen, die von 96 Entwicklern vorbereitet wurden, von denen 31 erstmals an der Entwicklung beteiligt sind. Die Hauptneuheiten sind: <\/p>\n
\n
Es wurde experimentelle Unterst\u00fctzung f\u00fcr eine neue Art von Bitkarten hinzugef\u00fcgt \u2014 das \u201epseudo-merge reachability bitmap\u201c. Im Gegensatz zur Struktur \u201ereachability bitmap\u201c werden die Daten \u00fcber Objekts\u00e4tze, die mit Commits verbunden sind, nicht an jeden einzelnen Commit gebunden, sondern an mehrere Commits gleichzeitig. Diese Organisation erm\u00f6glicht die Verwendung einer einzigen Bitkarte zur Bestimmung der Objekte f\u00fcr Commits in verschiedenen Branches, was in gro\u00dfen Repositories die Erstellung vieler einzelner Bitkarten \u00fcberfl\u00fcssig macht und die Objektdurchquerung erheblich beschleunigt, um zu bestimmen, welche Objekte dem Client bei Operationen wie \u201egit fetch\u201c, \u201egit rev-list\u201c und \u201egit clone\u201c gesendet werden m\u00fcssen. Um den neuen Typ von Bitkarten einzuf\u00fchren und die Logik f\u00fcr deren Auswahl und Verwendung festzulegen, wurde eine Reihe von Einstellungen \u201ebitmapPseudoMerge\u201c vorgeschlagen: git config bitmapPseudoMerge.all.pattern 'refs\/(heads|tags)\/' git config bitmapPseudoMerge.all.threshold now git config bitmapPseudoMerge.all.stableThreshold never git repack -adb\n
Eine neue Befehlszeilenschnittstelle f\u00fcr den Befehl «git config» wurde implementiert, die anstelle von verstreuten Optionen zum Anzeigen, Umbenennen und Entfernen von Einstellungen und Abschnitten, wie «—get», «—get-all», «—unset» und «—remove-section», eine Sammlung von separaten Subkommandos bietet. Zum Beispiel kann jetzt der Befehl «git config list» verwendet werden, um alle Einstellungen des Repositories anzuzeigen, und um den Inhalt eines bestimmten Parameters anzuzeigen, verwenden Sie den Befehl «git config get <Parametername>». Durch die Option «—regexp» k\u00f6nnen Ergebnisse zus\u00e4tzlich gefiltert werden, indem ein Filter auf Grundlage eines regul\u00e4ren Ausdrucks festgelegt wird.\n
Im Protokoll «credential helper», das zur \u00dcbertragung von Anmeldedaten beim Zugriff auf Repositories mit eingeschr\u00e4nktem Zugang verwendet wird, wurde die Unterst\u00fctzung neuer Felder «authtype» und «credential» hinzugef\u00fcgt. Diese erm\u00f6glichen die Erstellung von Handlern f\u00fcr HTTP-Authentifizierungssysteme, die \u00fcber die \u00dcberpr\u00fcfung von Benutzername und Passwort hinausgehen, zum Beispiel bei der Verwendung von Bearer Token in OAuth 2.0. Zuvor mussten f\u00fcr die Arbeit mit solchen Authentifizierungssystemen vertrauliche Daten im Klartext im Parameter http.extraHeader angegeben werden. Dar\u00fcber hinaus wurde im Protokoll die M\u00f6glichkeit hinzugef\u00fcgt, den Zustand jedes Anmeldedatenhandlers zu speichern, um mehrstufige Authentifizierungsmethoden zu unterst\u00fctzen, die in Protokollen wie NTLM und Kerberos verwendet werden.\n
Die Entwicklung des experimentellen Backends \u201ereftable\u201c wurde fortgesetzt, um eine effiziente Speicherung von Verweisen auf Branches und Tags im Repository zu erm\u00f6glichen. Dieses Backend verwendet den Blockspeicher, der im Projekt JGit verwendet wird, und ist f\u00fcr die Speicherung einer sehr gro\u00dfen Anzahl von Verweisen optimiert. Traditionelle Formate zur Speicherung von Verweisen f\u00fchren in Repositories mit einer Vielzahl von Verweisen zu erheblichen Overheadkosten, da bei der Speicherung von Verweisen im Verzeichnis $GIT_DIR\/refs eine sehr gro\u00dfe Anzahl von Dateien in einem einzigen Verzeichnis platziert werden muss oder beim Speichern von Verweisen in der Datei $GIT_DIR\/packed_refs jeder Aktualisierung eine gro\u00dfe Datei neu geschrieben werden muss. In der neuen Version wurde der Befehl \u201egit refs migrate \u2014ref-format=reftable\u201c hinzugef\u00fcgt, um bestehende Repositories auf das Backend \u201ereftable\u201c zu migrieren (zuvor wurde das Backend nur bei der Initialisierung des Repositories aktiviert).\n
Der Befehl git hat die Option \u201e\u2014no-advice\u201c hinzugef\u00fcgt, die alle Hinweise und Tipps deaktiviert. Dies kann n\u00fctzlich sein, um zu verhindern, dass das Log bei automatisierten Aufrufen von git mit unn\u00f6tigen Informationen vollgestopft wird.\n
Der Prozess zur \u00dcbertragung einiger Tests aus dem Testset auf die Verwendung von Unittests hat begonnen. Dies wird die Testung der Low-Level-Komponenten vereinfachen und die Effektivit\u00e4t des Testprozesses auf der Windows-Plattform erh\u00f6hen, auf der erhebliche Overheads beim Start von vielen Prozessen w\u00e4hrend der Ausf\u00fchrung von Tests, die als Shell-Skripte implementiert sind, entstehen.\n
In den Code zur Farbkonfiguration wurde die M\u00f6glichkeit hinzugef\u00fcgt, die Darstellung «#RGB» zus\u00e4tzlich zu «#RRGGBB» zu verwenden. <\/ul>\n