{"id":103093,"date":"2022-01-25T15:36:40","date_gmt":"2022-01-25T13:36:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35"},"modified":"2022-01-25T15:36:40","modified_gmt":"2022-01-25T13:36:40","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35","title":{"rendered":"Die Ver\u00f6ffentlichung des Quellcode-Management-Systems Git 2.35.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach zwei Monaten Entwicklung wurde die Version 2.35 des verteilten Quelltextverwaltungssystems Git ver\u00f6ffentlicht. Git geh\u00f6rt zu den beliebtesten, zuverl\u00e4ssigsten und leistungsst\u00e4rksten Versionsverwaltungssystemen und bietet flexible M\u00f6glichkeiten f\u00fcr nichtlineare Entwicklungen, die auf Branching und Merging basieren. Um die Integrit\u00e4t der Historie und die Widerstandsf\u00e4higkeit gegen \u00c4nderungen \u201er\u00fcckblickend\u201c sicherzustellen, wird ein implizites 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 validieren. <\/p>\n
Im Vergleich zur vorherigen Version wurden in die neue Version 494 \u00c4nderungen aufgenommen, die von 93 Entwicklern beigetragen wurden, von denen 35 zum ersten Mal an der Entwicklung beteiligt sind. Die wichtigsten Neuerungen sind: <\/p>\n
\n
Die M\u00f6glichkeiten zur Verwendung von SSH-Schl\u00fcsseln zur digitalen Signierung von Git-Objekten wurden erweitert. Um die G\u00fcltigkeitsdauer mehrerer Schl\u00fcssel zu differenzieren, wurde die Unterst\u00fctzung f\u00fcr die OpenSSH-Direktiven \u201evalid-before\u201c und \u201evalid-after\u201c hinzugef\u00fcgt, mit denen sichergestellt werden kann, dass Signaturen nach der Rotation des Schl\u00fcssels eines der Entwickler korrekt funktionieren. Zuvor gab es das Problem, alte und neue Schl\u00fcssel zu unterscheiden \u2014 wenn der alte Schl\u00fcssel gel\u00f6scht wurde, konnte man die mit ihm erstellten Signaturen nicht \u00fcberpr\u00fcfen, und wenn man ihn behielt, blieb die M\u00f6glichkeit bestehen, mit dem alten Schl\u00fcssel neue Signaturen zu erstellen, w\u00e4hrend bereits ein neuer Schl\u00fcssel bereitstand. Mit valid-before und valid-after kann der Geltungsbereich der Schl\u00fcssel basierend auf dem Zeitpunkt der Erstellung der Signatur getrennt werden.\n
In der Konfiguration merge.conflictStyle, die es erm\u00f6glicht, den Modus zur Darstellung von Konflikten beim Merging auszuw\u00e4hlen, wurde die Unterst\u00fctzung f\u00fcr den Modus \u201ezdiff3\u201c hinzugef\u00fcgt, der alle typischen Zeilen, die am Anfang oder Ende des Konflikts angegeben sind, au\u00dferhalb des Konfliktbereichs verschiebt. Dies erm\u00f6glicht eine kompaktere Darstellung der Informationen.\n
Das Kommando \u201egit stash\u201c hat den Modus \u201e--staged\u201c hinzugef\u00fcgt, der es erm\u00f6glicht, nur die \u00c4nderungen zu verstecken, die in den Index hinzugef\u00fcgt wurden. Dies ist beispielsweise n\u00fctzlich, wenn man einen Teil komplexer \u00c4nderungen vor\u00fcbergehend zur\u00fcckstellen m\u00f6chte, um zun\u00e4chst das Bereite hinzuzuf\u00fcgen und sich sp\u00e4ter um den Rest zu k\u00fcmmern. Der Modus \u00e4hnelt dem Kommando \u201egit commit\u201c, das nur die im Index befindlichen \u00c4nderungen aufzeichnet, aber anstelle eines neuen Commits wird das Ergebnis in den tempor\u00e4ren Bereich stash in \u201egit stash --staged\u201c gespeichert. Wenn die \u00c4nderungen sp\u00e4ter ben\u00f6tigt werden, k\u00f6nnen sie mit dem Befehl \u201egit stash pop\u201c wiederhergestellt werden.\n
Im Befehl «git log» wurde ein neuer Formatspezifizierer «—format=%(describe)» hinzugef\u00fcgt, der es erm\u00f6glicht, die Ausgabe von «git log» mit dem Ergebnis des Befehls «git describe» zu kombinieren. Die Parameter f\u00fcr «git describe» werden direkt im Spezifizierer angegeben («—format=%(describe:match=<foo>,exclude=<bar>)»), in dem auch verk\u00fcrzte Tags («—format=%(describe:tags=<bool>)») und die Anzahl der hexadezimalen Zeichen zur Identifizierung von Objekten («—format=%(describe:abbrev=<n>)») angepasst werden k\u00f6nnen. Zum Beispiel kann der folgende Befehl verwendet werden, um die letzten 8 Commits anzuzeigen, deren Tags nicht mit Release-Kandidaten gekennzeichnet sind, und um 8-stellige Identifikatoren anzugeben: $ git log -8 —format=’%(describe:exclude=*-rc*,abbrev=13)’ v2.34.1-646-gaf4e5f569bc89 v2.34.1-644-g0330edb239c24 v2.33.1-641-g15f002812f858 v2.34.1-643-g2b95d94b056ab v2.34.1-642-gb56bd95bbc8f7 v2.34.1-203-gffb9f2980902d v2.34.1-640-gdf3c41adeb212 v2.34.1-639-g36b65715a4132\n
In der Benutzerkonfiguration user.signingKey wurde die Unterst\u00fctzung neuer Schl\u00fcsseltpyen, die nicht auf den Typ «ssh-» und den vollst\u00e4ndigen Dateipfad zum Schl\u00fcssel beschr\u00e4nkt sind, implementiert. Alternative Typen werden mit dem Pr\u00e4fix «key::» angegeben, zum Beispiel «key::ecdsa-sha2-nistp256» f\u00fcr ECDSA-Keys.\n
Die Geschwindigkeit der Generierung von \u00c4nderungslisten im Modus «—histogram» sowie bei der Verwendung der Option «—color-moved-ws», die das Hervorheben von Leerzeichen in farbigen Diffs steuert, wurde deutlich erh\u00f6ht.\n
Im Befehl «git jump», der dazu dient, Vim genaue Informationen \u00fcber \u00dcberg\u00e4nge zu einer bestimmten Position in einer Datei beim Beheben von Merge-Konflikten, beim \u00dcberpr\u00fcfen von Unterschieden oder bei der Suchfunktion zu geben, wurde die M\u00f6glichkeit zur Eingrenzung der abgedeckten Merge-Konflikte bereitgestellt. Beispielsweise kann f\u00fcr die Einschr\u00e4nkung der Operationen auf das Verzeichnis «foo» der Befehl «git jump merge — foo» verwendet werden, w\u00e4hrend zur Ausschlie\u00dfung des Verzeichnisses «Documentation» der Befehl «git jump merge ‘:^Documentation'» verwendet werden kann.\n
Es wurde daran gearbeitet, den Typ «size_t» anstelle von «unsigned long» f\u00fcr Werte zu standardisieren, die die Gr\u00f6\u00dfe von Objekten darstellen, was die Anwendung der Filter «clean» und «smudge» mit Dateien \u00fcber 4 GB auf allen Plattformen, einschlie\u00dflich solcher mit dem LLP64-Datenmodell, erm\u00f6glicht, bei dem der Typ «unsigned long» auf 4 Byte begrenzt ist.\n
Der Befehl «git am» hat die Option «—empty=(stop|drop|keep)» hinzugef\u00fcgt, die es erm\u00f6glicht, beim Verarbeiten von Patches aus dem Posteingang das Verhalten f\u00fcr leere E-Mails, die keine Patches enthalten, auszuw\u00e4hlen. Der Wert «stop» f\u00fchrt zum Abbruch des gesamten Patch-Anwendungsprozesses, «drop» \u00fcberspringt den leeren Patch und «keep» erstellt einen leeren Commit.\n
Die Befehle «git reset», «git diff», «git blame», «git fetch», «git pull» und «git ls-files» unterst\u00fctzen jetzt partielle Indizes (sparse index), die die Leistung verbessern und Speicherplatz in Repositories sparen, in denen partielle Klonoperationen (sparse-checkout) durchgef\u00fchrt werden.\n
Der Befehl «git sparse-checkout init» ist als veraltet erkl\u00e4rt worden; stattdessen sollte der Befehl «git sparse-checkout set» verwendet werden.\n
Eine erste Implementierung eines neuen Backends «reftable» zur Speicherung von Referenzen wie Branches und Tags im Repository wurde hinzugef\u00fcgt. Das neue Backend verwendet einen Blockspeicher, der im JGit-Projekt verwendet wird und f\u00fcr die Speicherung einer sehr gro\u00dfen Anzahl von Referenzen optimiert ist. Das Backend ist derzeit noch nicht in das Referenzsystem (refs) integriert und bereit f\u00fcr die praktische Anwendung.\n
Die Farbpalette des Befehls «git grep» wurde an das GNU grep-Tool angepasst. <\/ul>\n