Veröffentlichung des verteilten Systems zur Verwaltung von Quelltexten Git 2.22

Vorstellung Veröffentlichung des verteilten Systems zur Verwaltung von Quelltexten Git 2.22.0. Git ist eines der beliebtesten, zuverlässigsten und leistungsstärksten Versionskontrollsysteme, das flexible Werkzeuge für die nichtlineare Entwicklung bietet, basierend auf Abzweigung und Zusammenführung von Zweigen. Um die Integrität der Historie und die Widerstandsfähigkeit gegen nachträgliche Änderungen zu gewährleisten, wird eine implizite Hashierung der gesamten vorherigen Historie in jedem Commit verwendet, auch die Authentifizierung von digitalen Signaturen der Entwickler für bestimmte Tags und Commits ist möglich.

Im Vergleich zur vorherigen Version wurden in die neue Version 745 Änderungen aufgenommen, die mit Beteiligung von 74 Entwicklern vorbereitet wurden, von denen 18 erstmals an der Entwicklung teilnahmen. Haupt- Neuheiten:

• Der ab Version 1.18 verfügbare neue Übertragungsmodus für das Commit-Set „git rebase —rebase-merges“ hat die alte Option „—preserve-merges“ ersetzt, die jetzt als veraltet gilt. Der Befehl „git rebase“ wird verwendet, um eine Serie von Commits durch einen neuen Basis-Commit zu ersetzen, beispielsweise um einen bestimmten Branch, in dem eine neue Funktion entwickelt wird, auf den aktuellen Stand des Master-Branches zu verschieben, der Korrekturen enthält, die nach der Abzweigung hinzugefügt wurden:

  o — o — o (my-feature)

  /

  o — o — o — o — o (master)

  o — o — o (my-feature)

  /

  o — o — o — o — o (master)

  Um die Struktur der Branches im übertragbaren Branch zu erhalten, konnte zuvor die Option „—preserve-merges“ verwendet werden, die im interaktiven Modus (git rebase -i —preserve-merges) das Bearbeiten der Commit-Historie erlaubte, jedoch keine vollständige Beibehaltung der Struktur des Repositories garantierte. Der neuerliche Modus „—rebase-merges“ ermöglicht es, die Struktur der Änderungen im übertragbaren Branch beizubehalten und bietet gleichzeitig eine vollständige Reihe interaktiver Operationen, einschließlich Löschen, Umgruppieren und Umbenennen von Commits.

  Zum Beispiel „—rebase-merges“ das Öffnen eines Links in einem neuen Tab oder in einem neuen Container. Commits aus einem einzelnen Branch auf einen neueren Master-Branch zu übertragen, dabei die Struktur der Branches im übertragbaren Branch zu bewahren und gleichzeitig einige Änderungen an den Commit-Nachrichten vorzunehmen.

• Unterstützung für die Erstellung eines neuen Branches basierend auf dem Ergebnis der Festlegung der Merge-Base zweier anderer Branches (Merge Basis, Bindung an den gemeinsamen Vorfahren) mittels der Konstruktionen „git branch new A…B“ und „git checkout -b new A…B“ hinzugefügt, wobei „A…B“ die Festlegung der Merge-Base zwischen zwei angegebenen Commits impliziert, ähnlich wie „git checkout A…B“ den HEAD auf den Basis-Commit verschiebt und „diff A…B“ die Änderungen zwischen dem Commit „B“ und dem gemeinsamen Vorfahren von Commit „A“ anzeigt.

  Zum Beispiel kann beim Arbeiten an einem separaten Branch my-feature die vorgeschlagene Funktion verwendet werden, wenn man von einem anderen Branch aus beginnen möchte, beispielsweise von dem Punkt im Master-Branch, an dem der Branch my-feature erstellt wurde. Zuvor war es erforderlich, das Änderungsprotokoll manuell zu durchsuchen, was bei umfangreichen Änderungsverläufen umständlich war. Man musste dann ‚git merge-base master my-feature‘ ausführen, um den Hash des Mergebasis zwischen den Branches master und my-feature zu berechnen, und einen neuen Branch relativ zum gemeinsamen Vorfahren erstellen: ‚git branch my-other-feature hash‘. In Git 2.22 kann zum Erstellen eines Branches relativ zur Merge-Base zweier anderer Branches die Syntax „git branch my-other-feature A…B“ verwendet werden;

• Die Option „git branch —show-current“ wurde hinzugefügt, um den Namen des Branches anzuzeigen, der nach der Ausführung der Checkout-Operation erhalten wurde;
• Die Option „git checkout —no-overlay — dir“ wurde hinzugefügt, um beim Ausführen der Checkout-Operation den Inhalt des Verzeichnisses dir in einen Zustand zu versetzen, der dem Zustand des Master-Branches vollständig entspricht. Wenn im lokalen Kopie des Verzeichnisses dir eine Datei vorhanden ist, die im Master-Branch fehlt, wird sie standardmäßig bei „git checkout master — dir“ belassen, während sie bei Angabe der Option „—no-overlay“ gelöscht wird;
• In der ‚git diff‘-Befehlszeile wurde eine universelle API zur Analyse von Optionen implementiert, was eine einheitliche Verarbeitung der Optionen mit anderen Git-Tools ermöglicht hat. Beispielsweise sind in ‚git diff‘ jetzt für alle Optionen deren Antagonisten verfügbar („—function-context“ und „—no-function-context“);
• Die Möglichkeit zur Filterung beim Ausgeben von ‚git log‘ von an die Commits angehängten erweiterten Labels („trailer“ — zusätzliche Informationsflags wie Signiert-von und Co-Author-von) wurde hinzugefügt. Eine Filterung der Labels ist sowohl nach Schlüssel als auch nach Wert möglich, zum Beispiel:
  „git log —pretty=„%(trailers:key=Reviewed-by,valueonly)“;
• Ein neuer Trace2-Tracking-Mechanismus wurde hinzugefügt, der ein flexibleres und strukturiertes Ausgabeformat bietet. Trace2 ermöglicht das Sammeln von Telemetriedaten über ausgeführte Operationen und Leistungsdaten für eine detailliertere Analyse und Fehlersuche (der Handler wird vom Benutzer zugewiesen, keine Daten werden nach außen gesendet);
• Der Bericht „git bisect“ wurde lesbarer gestaltet, wobei problematische Commits nun deutlicher hervorgehoben werden und eine zusammenfassende Statistik zu den Änderungen für jede Datei (auf der Ebene der Anzahl der geänderten Zeilen) ausgegeben wird;
• Die Heuristik zur Erkennung von Umbenennungen von Verzeichnissen wurde überarbeitet, um falsche Umbenennungsmarkierungen zu vermeiden. Bei Zweifeln werden solche Verzeichnisse nun als konfliktierend gekennzeichnet;
• Es wird eine Warnung ausgegeben, wenn versucht wird, ein Tag auf ein anderes Tag zu setzen, was in der Regel ein Fehler ist und dazu führen kann, dass das Tag nicht auf den richtigen Commit gesetzt wird (zum Beispiel führt eine Konstruktion wie „git tag -f -m „updated message“ my-tag1 my-tag2“ dazu, dass ein Tag auf ein altes Tag gesetzt wird, während der Entwickler erwartet, dass das neue Tag auf den Commit gesetzt wird, auf den das alte Tag verweist);
• Die Generierung von Reachability-Bitmaps für Repositories wurde aktiviert, die Daten über Objektmengen speichern, die für jeden Commit verfügbar sind, und es ermöglichen, schnell das Vorhandensein eines Basisobjekts zu bestimmen. Die angegebene Struktur verkürzt die Dauer der Datenausführungen (git fetch) erheblich.

Quelle: opennet.ru