Mergestrategien und Squash-Merge

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

Wenn Sie eine Pullanforderung abschließen, führen Sie die Themenverzweigung in Ihrer Standardverzweigung zusammen, in der Regel 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 in Ihrem main Zweig (oder einem anderen Standardzweig) folgt wegen des verbundenen Themenzweigverlaufs nicht einer 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.

Die Standardzweig stellt den Verlauf der einzelnen Themenzweige genau dar, aber es ist schwierig, anhand dessen breitere Fragen zur Entwicklung Ihres Projekts zu beantworten.

Voraussetzungen

Squash-Zusammenführung

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 Feature-Branch. Es erzeugt einen neuen Commit , der alle Änderungen aus dem Themenzweig enthält. Es wird empfohlen, den Themenzweig zu löschen, um Verwirrung zu vermeiden.

Eine einfache Möglichkeit, darüber nachzudenken, besteht darin, dass der Squash-Merge Ihnen nur die Dateiänderungen bietet, und ein normaler Merge gibt Ihnen sowohl die Dateiänderungen als auch den Commit-Verlauf.

Wie ist ein Squash-Merge hilfreich?

Squash-Merging hält Ihre Standard-Zweig-Historien sauber und leicht nachvollziehbar, ohne dass Änderungen im Arbeitsablauf Ihres Teams erforderlich sind. Mitwirkende an der Themenverzweigung arbeiten nach ihren eigenen Vorlieben in der Themenverzweigung, und die Standardzweige behalten eine lineare Geschichte durch die Verwendung von Squash-Merges. Der Commit-Verlauf eines main Branch, der mit Squash-Merges aktualisiert wurde, hat einen Commit für jede zusammengeführte Branch. Sie können diesen Verlauf schrittweise durchlaufen, um genau herauszufinden, wann die Arbeit abgeschlossen wurde.

Überlegungen beim Squash-Merging

Beim Squash-Merging wird die Historie der Änderungen in Ihrer Standardverzweigung verdichtet, daher ist es wichtig, mit Ihrem Team zusammenzuarbeiten, um zu entscheiden, wann Sie ein Squash-Merging anwenden möchten und wann es sinnvoll ist, die vollständige Commit-Historie eines Themenzweigs beizubehalten. Beim Squash-Merging sollte man den Quellzweig löschen. Durch das Löschen der Quellverzweigung wird Verwirrung verhindert, da die Themenverzweigung selbst keinen Commit zum Zusammenführen in die Standardverzweigung hat.

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 Merge-Basen zwischen den Verzweigungen vorhanden sind. 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 Liste der angezeigten Commits ist möglicherweise unvollständig" für die PR. 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 als Criss-Cross bezeichnet) zwischen verschiedenen Zweigniederlassungen (berichtet von Azure DevOps und git merge-base)

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

• Zusammenführung eines Branches in zwei andere (von Azure DevOps gemeldet, jedoch nicht von git merge-base, der die Zusammenführungsbasis 2 eliminiert)

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

• Behandlung von Rückgängen der Hauptverzweigung, z. B. Ändern des Zusammenführungs-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 komplexe Manipulationen mit Reverts, Cherry-Picks und Zusammenführungen

Die Erkennung mehrerer Zusammenführungsgrundlagen ist Teil des Sicherheitsbewusstseins. Wenn mehrere Zusammenführungsbasen vorhanden sind, erkennt der Datei-Diff-Algorithmus für die Benutzeroberfläche möglicherweise keine Dateiänderungen, je nachdem, welche Zusammenführungsbasis gewählt wird. 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 BENUTZERoberflächenalgorithmus missbrauchen, um böswillige Änderungen zu übernehmen, die in der PR nicht vorhanden 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.

Behebung des Problems mit mehreren Merge-Basen

Mehrere Zusammenführungsbasen zu haben, ist nicht unbedingt schlecht, aber Sie sollten überprüfen, ob alles in Ordnung ist. Um mehrere Merge-Basen zu entfernen, binden Sie die Verzweigungen an einen einzelnen gemeinsamen Vorfahren, indem Sie Ihre Verzweigung entweder auf das Ziel rebasisieren oder das Ziel in Ihren Branch mergen. Diese Aktionen entfernen die Warnmeldung und helfen Ihnen zu überprüfen, ob die tatsächlichen Änderungen in Ordnung sind.

Ein Ansatz besteht darin, den Fortschritt vor dem Neubasieren oder Zusammenführen vorläufig zurückzusetzen und zu schieben. Anschließend können Sie einen neuen Branch oder einen leeren Branch rebasen und Ihre Änderungen ab einem klar definierten Punkt anwenden. Bei diesem Vorgang ist möglicherweise ein Erzwungener Push auf remote erforderlich, wenn Ihre Änderungen bereits vorhanden sind.

So vermeiden Sie das Problem mit mehreren Merge-Basen

Hier sind allgemeine Tipps zur Vermeidung des Problems mit mehreren Verzweigungsbasen:

• Erstellen Sie bei der Vorbereitung einer Pullanforderung Funktionszweige aus den neuesten Versionen der Haupt- oder Release-Verzweigung.
• Vermeiden Sie das Erstellen von Verzweigungen, die nicht direkt aus stabilen Verzweigungen Ihres Repositorys stammen, es sei denn, dies ist erforderlich.

Was zu tun ist, wenn das Problem mit mehreren Zusammenführungsbasen wieder auftritt

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 eine langjährige Pull-Anfrage schließt, kann dies die Situation erneut hervorrufen. Obwohl Buildrichtlinien und Tests ausgeführt werden, haben Sie keine Möglichkeit, die Pullanforderung abzuschließen. Das Zurücksetzen und Starten eines neuen Branches kann hilfreich sein. 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