Mergestrategien und Squashmerge

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Wenn Sie einen Pull Request abschließen, führen Sie den Topic-Branch mit Ihrem Standardbranch zusammen, normalerweise main. Mit diesem Merge werden die Commits des Topic-Branches zu Ihrem Main-Branch hinzugefügt und ein Merge-Commit erstellt, um Konflikte zwischen dem Default- und dem Topic-Branch zu beheben. Die Kommentare und Diskussionen im Pull-Request geben mehr Kontext für die Änderungen, die im Topic-Branch vorgenommen wurden.

Der Commitverlauf für Ihren main-Branch (oder einem anderen Standardbranch) folgt aufgrund des Verlaufs des zugehörigen Topic-Branchs keiner geraden Linie. Da ein Projekt größer wird, steigt die Anzahl der Themenzweige, an denen gleichzeitig gearbeitet wurde, wodurch die Standardzweiggeschichte immer schwieriger zu verfolgen ist.

Der Standardbranch ist eine genaue Darstellung des Verlaufs der einzelnen Topic-Branches, aber er ist schwer für die Beantwortung allgemeiner Fragen zur Entwicklung Ihres Projekts zu verwenden.

Voraussetzungen

Squashmerge

Squash-Zusammenführen ist eine Zusammenführungsoption, mit der Sie den Git-Verlauf von Themenzweigen komprimieren können, wenn Sie einen Pull-Request abschließen. Anstatt jeden Commit in der Themenverzweigung zur Historie der Standardverzweigung hinzuzufügen, fasst ein Squash-Merge alle Dateiänderungen zu einem einzigen neuen Commit auf der Standardverzweigung zusammen. Der Squash-Merge-Commit hat keinen Verweis auf den Topic-Branch. Es wird ein neuer Commit erstellt, der alle Änderungen aus dem Topic-Branch enthält. Es wird empfohlen, den Themenzweig zu löschen, um Verwirrung zu vermeiden.

Eine einfache Art, sich das vorzustellen, besteht darin, dass Sie bei einem Squashmerge nur die Dateiänderungen erhalten, während Sie bei einem regulären Mergevorgang die Dateiänderungen und den Commitverlauf erhalten.

Wie ist ein Squash-Merge hilfreich?

Durch den Squashmerge bleiben Ihre standardmäßigen Branchverläufe übersichtlich und leicht nachvollziehbar, ohne dass Ihr Team Änderungen am Workflow vornehmen muss. Die Mitwirkenden am Topic-Branch arbeiten nach Belieben am Topic-Branch und die Standardbranches behalten mithilfe von Squashmerges einen linearen Verlauf. Der Commitverlauf eines main-Branchs, der mit Squashmerges aktualisiert wurde, enthält einen Commit für jeden zusammengeführten Branch. Sie können diesen Verlauf schrittweise durchlaufen, um genau herauszufinden, wann die Arbeit abgeschlossen wurde.

Überlegungen beim Squash-Merging

Beim Squashmerge wird der Verlauf der Änderungen in Ihrem Standardbranch komprimiert. Es ist daher wichtig, dass Sie gemeinsam mit Ihrem Team entscheiden, wann ein Squashmerge durchgeführt werden soll und wann der vollständige Commitverlauf eines Topic-Branchs beibehalten werden soll. Beim Squashmerge ist es eine bewährte Methode, den Quellbranch zu löschen. Das Löschen des Quellbranchs verhindert Verwirrung, da der Topic-Branch selbst keinen Commit aufweist, der ihn mit dem Standardbranch zusammenführt.

Mehrere Zusammenführungsbasen

Die Registerkarte "Dateien" in einem Pull-Request erkennt Diffs anhand eines dreiseitigen Vergleichs. Der Algorithmus berücksichtigt den letzten Commit in der Zielbranche, den letzten Commit in der Quellbranche und ihre gemeinsame Zusammenführungsbasis, beispielsweise den besten gemeinsamen Vorgänger. Der Algorithmus ist eine schnelle, kosteneffiziente und zuverlässige Methode zum Erkennen von Änderungen. Leider gibt es in manchen Fällen mehr als eine echte Basis. In den meisten Repositorys ist dies selten, aber in großen Repositorys mit vielen aktiven Benutzern kann es üblich sein. Sie können manuell überprüfen, ob mehrere Mergebasen zwischen den Branches existieren. Führen Sie dazu den Befehl aus git merge-base --all feature master . Azure DevOps erkennt das Vorhandensein mehrerer Zusammenführungsbasen für jede PR. Wenn diese erkannt werden, zeigt Azure DevOps die Meldung "Mehrere Zusammenführungsbasen erkannt. Die angezeigte Liste der Commits ist möglicherweise unvollständig“. Während Azure DevOps die Erkennung mehrerer Zusammenführungsbasen ausführt, wird nicht überprüft, ob die potenzielle Zusammenführungsbasis bereits zusammengeführt wurde oder nicht. Diese Überprüfung erfolgt durch git merge-base. Aus diesem Grund zeigt Azure DevOps möglicherweise die Meldung auch dann an, wenn git merge-base nur eine Zusammenführungsbasis meldet.

Die folgenden Beispielszenarien werden von Azure DevOps als mehrere Basen erkannt, wobei die Zusammenführungsbasen durch Zahlen 1 und zwei angegeben sind:

• Cross-Merges (auch Criss-Cross genannt) zwischen verschiedenen Branches (von Azure DevOps und git merge-base gemeldet)

---1---o---A
    \ /
     X
    / \
---2---o---o---B

• Zusammenführen eines Branches mit zwei anderen (von Azure DevOps angegeben, aber nicht von git merge-base, wodurch die Mergebasis 2 entfällt)

---1---o---o---o---A
    \         /
     \-------2
      \       \
       \---o---o---o---B

• Handhabung der Konsequenzen von Reverts des Hauptbranch, zum Beispiel Änderung des Merge-Commits

*   42bb2d2 (HEAD, A) Amended merge commit
|\  
| | *   67c9bb8 (other) Merge branch 'A' into B
| | |\  
| |/ /  
|/| /   
| |/    
| * fa78e32 add second commit
* | 15845c9 add first commit
|/  
* 6a52130 add init

• Aktive Wiederverwendung von Featureverzweigungen
• Andere nicht intuitive und verworrene Manipulationen mit Wiederherstellung, Cherrypicking und Mergevorgängen.

Die Erkennung mehrerer Zusammenführungsgrundlagen ist Teil des Sicherheitsbewusstseins. Wenn es mehrere Mergebasen gibt, kann es sein, dass je nach gewählter Mergebasis der Dateivergleichsalgorithmus für die Benutzeroberfläche Dateiänderungen nicht ordnungsgemäß erkennt. Wenn die Dateien in der Pullanforderung unterschiedliche Versionen zwischen den Zusammenführungsbasen aufweisen, tritt eine Mehrfachzusammenführungsbasiswarnung auf.

Weitere Details erhalten Sie in der offiziellen Git-Dokumentation .

Potenzielle Sicherheitsrisiken der Zusammenführung aus mehreren Basen

• Ein böswilliger Benutzer könnte den UI-Algorithmus missbrauchen, um böswillige Änderungen zu committen, die nicht im PR enthalten sind.
• Wenn Änderungen, die im PR vorgeschlagen werden, bereits in der Zielbranch enthalten sind, werden sie auf der Registerkarte Dateien angezeigt, lösen jedoch möglicherweise keine Branch-Richtlinien aus, die auf Ordneränderungen angewendet werden.
• Zwei Gruppen von Änderungen an denselben Dateien aus mehreren Zusammenführungsbasen sind möglicherweise nicht in der PR vorhanden. In diesem Fall könnten trügerische Logiklücken entstehen.

Beheben des Problems mehrerer Mergebasen

Mehrere Zusammenführungsbasen zu haben, ist nicht unbedingt schlecht, aber Sie sollten überprüfen, ob alles in Ordnung ist. Um das Problem mehrerer Mergebasen zu beseitigen, binden Sie die Branches an einen einzelnen gemeinsamen Vorgänger, indem Sie entweder ein Rebase für Ihren Branch zum Zielbranch ausführen oder den Zielbranch in Ihren Branch zusammenführen. Diese Aktionen entfernen die Warnmeldung und helfen Ihnen zu überprüfen, ob die tatsächlichen Änderungen in Ordnung sind.

Eine Möglichkeit besteht darin, einen Warmstart durchzuführen und einen Stash für Ihren Status auszuführen, bevor Sie ein Rebase oder einen Mergevorgang ausführen. Sie können dann einen neuen Branch erstellen oder für einen leeren Branch ein Rebase ausführen und Ihre Änderungen von einem bereinigten Punkt aus anwenden. Dieser Vorgang erfordert möglicherweise einen erzwungenen Push zum Remotespeicherort, wenn sich Ihre Änderungen bereits dort befinden.

So vermeiden Sie das Problem mit mehreren Merge-Basen

Hier finden Sie allgemeine Tipps, wie Sie das Problem mehrerer Mergebasen vermeiden können:

• Wenn Sie einen Pull Request vorbereiten, erstellen Sie Featurebranches aus den neuesten Versionen des Main- oder Releasebranchs.
• Vermeiden Sie das Erstellen von Verzweigungen, die nicht direkt aus stabilen Verzweigungen Ihres Repositorys stammen, es sei denn, dies ist erforderlich.

Vorgehensweise beim erneuten Auftreten des Problems mehrerer Mergebasen

In großen Repositories mit vielen aktiven Mitwirkenden kann dieses Problem besonders unangenehm sein. Auch wenn Sie mehrere Basen über die Zusammenführung loswerden, könnte die Situation wieder auftreten. Wenn jemand einen seit langem bestehenden Pull Request schließt, kann das die Situation erneut hervorrufen. Obwohl Buildrichtlinien und Tests ausgeführt werden, haben Sie keine Möglichkeit, den Pull Request abzuschließen. Das Zurücksetzen und Starten eines neuen Branchs könnte helfen. Wenn nichts geändert wird, sind Ihre Änderungen wahrscheinlich klar, auch wenn sich die Situation wiederholt.

Nächste Schritte

• Auflösen von Zusammenführungskonflikten
• Abschließen einer Pullanforderung
• Informationen zu Pullanforderungen