Die Ausgabe des verteilten Systems zur Verwaltung von Quelltexten Git 2.22

Präsentiert Veröffentlichung des verteilten versionierten Systems Git 2.22.0. Git ist eines der beliebtesten, zuverlässigsten und leistungsstärksten Versionskontrollsysteme, das flexible Mittel für die nichtlineare Entwicklung bereitstellt, die auf Branching und Merging basieren. Zur Gewährleistung der Integrität der Historie und der Widerstandsfähigkeit gegenüber nachträglichen Änderungen wird die gesamte vorherige Historie in jedem Commit implizit gehasht. Zudem ist es möglich, digitale Signaturen für bestimmte Tags und Commits durch die Entwickler zu verifizieren.

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

• Der seit der Version 1.18 verfügbare neue Modus zur Übertragung von Commit-Sets „git rebase —rebase-merges“ ersetzt die alte Option „—preserve-merges“, die jetzt als veraltet markiert ist. Der Befehl „git rebase“ wird verwendet, um eine Reihe von Commits durch einen neuen Basis-Commit zu ersetzen, beispielsweise um einen bestimmten Branch, in dem ein neues Feature entwickelt wird, an den aktuellen Stand des Master-Branches zu verschieben, der nach dem Abzweigen hinzugefügte Korrekturen umfasst:

  o — o — o (my-feature)

  /

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

  o — o — o (my-feature)

  /

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

  Um die Verzweigungsstruktur in einem übertragbaren Branch zu bewahren, konnte zuvor die Option „—preserve-merges“ verwendet werden. Diese erlaubte im interaktiven Modus (git rebase -i —preserve-merges) das Bearbeiten der Commit-Geschichte, garantierte jedoch nicht die vollständige Erhaltung der Repository-Struktur. Der neue Modus „—rebase-merges“ ermöglicht es, die Struktur der Änderungen im übertragbaren Branch beizubehalten, während er ein vollständiges Set an interaktiven Operationen bereitstellt, inklusive Löschen, Umgruppieren und Umbenennen von Commits.

  Zum Beispiel „—rebase-merges“ ermöglicht es Commits aus einem separaten Branch in einen neueren Master-Branch zu übernehmen, dabei die Verzweigungsstruktur im übertragbaren Branch zu bewahren und gleichzeitig einige Änderungen in den Commit-Notizen vorzunehmen.

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

  Zum Beispiel kann die vorgeschlagene Funktion beim Arbeiten an einem separaten Branch my-feature verwendet werden, wenn es erforderlich ist, von einem anderen Branch zu starten, beispielsweise von dem gleichen Punkt im Master-Branch, von dem der Branch my-feature abgezweigt wurde. Bisher war es notwendig, manuell das Änderungsprotokoll zu überprüfen, was bei einer umfangreichen Änderungshistorie unpraktisch war, und dann „git merge-base master my-feature“ auszuführen, um den Hash der Merge-Base zwischen den Branches master und my-feature zu berechnen und einen neuen Branch relativ zum gemeinsamen Vorfahren mit „git branch my-other-feature Hash“ zu erstellen. In Git 2.22 kann der Befehl „git branch my-other-feature A…B“ verwendet werden, um einen Branch relativ zur Merge-Base zweier anderer Branches zu erstellen.

• Die Option „git branch —show-current“ wurde hinzugefügt, um den Namen des Branches bei der Ausführung der Checkout-Operation anzuzeigen;
• Die Option „git checkout —no-overlay —dir“ wurde hinzugefügt, die es ermöglicht, den Inhalt des Verzeichnisses dir beim Checkout so zu gestalten, dass er vollständig dem Zustand des Master-Branches entspricht. Beispielsweise bleibt eine Datei in der lokalen Kopie des Verzeichnisses dir, die im Master-Branch fehlt, standardmäßig bei „git checkout master — dir“, während sie bei Angabe der Option „—no-overlay“ gelöscht wird;
• In dem Befehl „git diff“ wurde eine universelle API zur Analyse der Optionen integriert, was eine einheitliche Verarbeitung der Optionen mit anderen Git-Dienstprogrammen ermöglichte. Beispielsweise sind für alle Optionen jetzt auch ihre Antagonisten („—function-context“ und „—no-function-context“) verfügbar;
• Die Möglichkeit zur Filterung von erweiterten Labels („trailer“ — zusätzliche Informationsflags wie Signed-off-by und Co-authored-by), die an Commits angehängt werden, wurde beim Ausgeben von „git log“ hinzugefügt. Es kann nach Schlüssel und Wert gefiltert werden, z. B.:
  „git log —pretty=„%(trailers:key=Reviewed-by,valueonly)“;
• Ein neuer Trace2-Tracking-Mechanismus wurde hinzugefügt, der ein flexibleres und strukturierteres Ausgabenformat bietet. Trace2 ermöglicht die Erfassung von Telemetriedaten über durchgeführte Operationen und Leistungsdaten für eine detailliertere Analyse und Fehlersuche (der Handler wird vom Benutzer zugewiesen, es werden keine Daten nach außen gesendet);
• Der Bericht „git bisect“ wurde lesbarer gestaltet und hebt jetzt die problematischen Commits deutlicher hervor sowie erstellt eine Zusammenfassung der Änderungen für jede Datei (auf der Ebene der geänderten Zeilen);
• Die Heuristik zur Bestimmung von Umbenennungen von Verzeichnissen wurde überarbeitet, um falsche Umbenennungsmarkierungen auszuschließen. Bei Zweifeln werden solche Verzeichnisse nun als konfliktbehaftet markiert;
• Eine Warnung wird ausgegeben, wenn versucht wird, ein Tag auf ein anderes Tag zu setzen, was in der Regel versehentlich geschieht und dazu führen kann, dass ein 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 erstellt wird, während der Entwickler davon ausgeht, dass das neue Tag auf den Commit gesetzt wird, auf den das alte Tag zeigt);
• Die Generierung für Bitmapp-Repositorys (die Datenstruktur „Reachability Bitmaps“), die Informationen über verfügbare Objektsets für jeden Commit speichert und es ermöglicht, das Vorhandensein des Basisobjekts schnell zu bestimmen, ist aktiviert. Diese Struktur verkürzt die Ausführungszeit von Datenabrufoperationen (git fetch) erheblich.

Quelle: opennet.ru