Veröffentlichung des verteilten Versionsverwaltungssystems Git 2.22

Eingereicht von Veröffentlichung eines verteilten Versionsverwaltungssystems Git 2.22.0. Git ist eines der beliebtesten, zuverlässigsten und leistungsstärksten Versionskontrollsysteme und bietet flexible nichtlineare Entwicklungstools basierend auf Verzweigung und Zusammenführung. Um die Integrität des Verlaufs und den Widerstand gegen rückwirkende Änderungen sicherzustellen, wird implizites Hashing des gesamten vorherigen Verlaufs in jedem Commit verwendet. Darüber hinaus ist es möglich, einzelne Tags und Commits mit digitalen Signaturen von Entwicklern zu zertifizieren.

Im Vergleich zur Vorgängerversion enthielt die neue Version 745 Änderungen, die unter Beteiligung von 74 Entwicklern erstellt wurden, von denen 18 erstmals an der Entwicklung beteiligt waren. Haupt- Innovationen:

• Der seit Release 1.18 verfügbare neue Commit-Rebase-Modus „git rebase --rebase-merges“ ersetzt die alte Option „--preserve-merges“, die jetzt veraltet ist. Die Operation „git rebase“ wird verwendet, um eine Reihe von Commits durch ein neues Basis-Commit zu ersetzen, um beispielsweise einen separaten Zweig, der eine neue Funktion entwickelt, in den aktuellen Status des Master-Zweigs zu verschieben, der nach dem Zweig hinzugefügte Korrekturen enthält :

  o - o - o (mein-Feature)

  /

  o - o - o - o - o (Meister)

  o - o - o (mein-Feature)

  /

  o - o - o - o - o (Meister)

  Um die Zweigstruktur in einem migrierten Zweig beizubehalten, konnte zuvor die Option „--preserve-merges“ verwendet werden, die bei Ausführung im interaktiven Modus (git rebase -i --preserve-merges) das Bearbeiten des Commit-Verlaufs ermöglichte, aber konnte keine vollständige Erhaltung der Repository-Struktur gewährleistet werden. Mit dem neuen Modus „--rebase-merges“ können Sie die Struktur der Änderungen im zu migrierenden Zweig beibehalten und gleichzeitig eine vollständige Palette interaktiver Vorgänge bereitstellen, einschließlich Löschen, Neugruppieren und Umbenennen von Commits.

  Beispiel: „--rebase-merges“ ermöglicht Laden Sie Commits von einem separaten Zweig in einen neueren Master-Zweig erneut hoch, während Sie die Zweigstruktur im migrierten Zweig beibehalten, und nehmen Sie spontan einige Änderungen an den Commit-Notizen vor.

• Unterstützung für die Erstellung eines neuen Zweigs basierend auf dem Ergebnis der Bestimmung der Zusammenführungsbasis zweier anderer Zweige (Zusammenführungsbasis, Bindung an einen gemeinsamen Vorfahren) mithilfe der Konstruktionen „git branch new A...B“ und „git checkout -b new“ hinzugefügt A...B“, wobei „A ...B“ das Definieren einer Zusammenführungsbasis zwischen zwei angegebenen Commits beinhaltet, ähnlich wie „git checkout A...B“ den HEAD zum Basis-Commit verschiebt und „diff A. ..B“ zeigt die Änderungen zwischen Commit „B“ und Commit „A“ „Ancestor“.

  Wenn Sie beispielsweise an einem separaten My-Feature-Zweig arbeiten, kann diese Funktion verwendet werden, wenn Sie von einem anderen Zweig aus beginnen möchten, beispielsweise von derselben Stelle im Master-Zweig, von der aus der My-Feature-Zweig ausgecheckt wurde. Bisher war hierfür eine manuelle Untersuchung des Änderungsprotokolls erforderlich, was unpraktisch war, wenn Sie über einen umfangreichen Änderungsverlauf verfügten, und anschließend die Ausführung von „git merge-base master my-feature“, um den Hash der Zusammenführungsbasis zwischen den Zweigen „master“ und „my-feature“ zu berechnen und Erstellen eines neuen Zweigs relativ zum gemeinsamen Vorfahren „git branch my-other-feature hash“. In Git 2.22 können Sie die Syntax „git branch my-other-feature A...B“ verwenden, um einen Zweig relativ zur Merge-Basis zweier anderer Zweige zu erstellen;

• Option „git branch --show-current“ hinzugefügt, um den Namen des Zweigs anzuzeigen, der während des Auscheckvorgangs erhalten wurde;
• Die Option „git checkout –no-overlay – dir“ wurde hinzugefügt, die es ermöglicht, beim Ausführen eines Checkout-Vorgangs den Inhalt des Dir-Verzeichnisses in eine Form zu bringen, die vollständig dem Status des Hauptzweigs entspricht. Wenn sich beispielsweise in der lokalen Kopie des dir-Verzeichnisses eine Datei befindet, die sich nicht im Master-Zweig befindet, wird diese beim Ausführen von „git checkout master - dir“ standardmäßig belassen, und wenn „--no-overlay ”-Option angegeben wird, wird sie gelöscht;
• Der Befehl „git diff“ verwendet eine universelle API zum Parsen von Optionen, die es ermöglicht, die Optionsbehandlung mit anderen Git-Dienstprogrammen zu vereinheitlichen. Beispielsweise haben in „git diff“ jetzt alle Optionen ihre Gegenspieler („--function-context“ und „--no-function-context“);
• Es wurde die Möglichkeit hinzugefügt, erweiterte Tags zu filtern, die an Commits in der „Git-Log“-Ausgabe angehängt sind („Trailer“ – zusätzliche Informationsflags, wie „Signed-off-by“ und „Co-authored-by“). Es ist möglich, Beschriftungen sowohl nach Schlüssel als auch nach Wert zu filtern, zum Beispiel:
  "git log --pretty="%(trailers:key=Reviewed-by,valueonly)";

• Eine neue Tracing-Engine, Trace2, wurde hinzugefügt und bietet ein flexibleres und strukturierteres Ausgabeformat. Mit Trace2 können Sie Telemetriedaten zu ausgeführten Vorgängen und Leistungsdaten für eine detailliertere Analyse und Fehlerbehebung sammeln (der Handler wird vom Benutzer zugewiesen, es werden keine Daten nach außen gesendet).
• Der „git bisect“-Bericht wurde besser lesbar gemacht, in dem problematische Commits jetzt klarer hervorgehoben werden und zusammenfassende Statistiken zu Änderungen für jede Datei angezeigt werden (auf der Ebene der Anzahl der geänderten Zeilen);
• Die Heuristik zur Ermittlung von Verzeichnisumbenennungen wurde überarbeitet, um die falsche Installation von Umbenennungskennzeichnungen zu verhindern. Im Zweifelsfall werden solche Verzeichnisse nun als widersprüchlich gekennzeichnet;
• Eine Warnung wird angezeigt, wenn Sie versuchen, ein Tag auf einem anderen Tag zu installieren, was normalerweise versehentlich geschieht und dazu führen kann, dass das Tag auf dem falschen Commit gesetzt wird (z. B. eine Konstruktion wie „git tag -f -m „aktualisierte Nachricht“). „my-tag1 my-tag2“ führt dazu, dass ein Tag auf dem alten Tag erstellt wird, während der Entwickler erwartet hat, dass das neue Tag auf dem Commit installiert wird, auf das das alte Tag zeigt);
• Die Generierung ist für Bitmap-Repositorys (festplattenbasierte „Erreichbarkeits-Bitmaps“-Struktur) aktiviert, die Daten über für jeden Commit verfügbare Objektsätze speichern und es Ihnen ermöglichen, schnell das Vorhandensein eines Basisobjekts zu bestimmen. Diese Struktur reduziert die Ausführungszeit von Datenabrufvorgängen (Git Fetch) erheblich.

Source: opennet.ru