Mergestrategien und Squashmerge
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Wenn Sie einen Pull Request abschließen, führen Sie den Topic-Branch mit Ihrem Standardbranch zusammen, normalerweise main. Dieser Mergevorgang fügt die Commits des Topic-Branchs zu Ihrem Mainbranch hinzu und erstellt einen Mergecommit, um etwaige Konflikte zwischen dem Standard- und dem Topic-Branch auszugleichen. Die Kommentare und die Diskussion im Pull Request bieten zusätzlichen 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. Wenn ein Projekt größer wird, steigt die Anzahl der Topic-Branches, an denen gleichzeitig gearbeitet wird, sodass dem Verlauf des Standardbranchs immer schwerer zu folgen 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.
Squashmerge
Squashmerge ist eine Mergeoption, mit der Sie den Git-Verlauf von Topic-Branches zusammenfassen können, wenn Sie einen Pull Request abschließen. Anstatt jeden Commit auf dem Topic-Branch zum Verlauf des Standardbranchs hinzuzufügen, fügt ein Squashmerge alle Dateiänderungen zu einem einzelnen neuen Commit auf dem Standardbranch hinzu. Der Squash-Merge-Commit hat keinen Verweis auf den Topic-Branch, sondern erzeugt einen neuen Commit, der alle Änderungen aus dem Topic-Branch enthält. Außerdem wird empfohlen, den Topic-Branch zu löschen, um Verwirrungen 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.
Inwiefern ist ein Squashmerge 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 durchlaufen, um zu ermitteln, wann genau die Arbeiten durchgeführt wurden.
Überlegungen zum Squashmerge
Beim Squashmerge wird der Verlauf der Änderungen in Ihrem Standardbranch komprimiert. Es ist daher wichtig, dass Sie gemeinsam mit Ihrem Team entscheiden, wann Sie einen Squashmerge durchführen sollten oder wann Sie den vollständigen Commitverlauf eines Branchs behalten möchten. 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.
Abschließen von Pull Requests mit Squashmerge
Sie können beim Abschließen von Pull Requests in Azure Repos einen Squashmerge auswählen.
Wählen Sie Squashcommit unter Mergetyp im Dialogfeld Pull Request abschließen aus, um für den Topic-Branch einen Squashmerge durchzuführen.
Mehrere Mergebasen
Auf der Registerkarte Dateien in einem Pull Request werden Unterschiede durch einen dreiseitigen Vergleich erkannt. Der Algorithmus berücksichtigt den letzten Commit im Zielbranch, den letzten Commit im Quellbranch und ihre gemeinsame Mergebasis (d. h. den besten gemeinsamen Vorgänger). Der Algorithmus ist eine schnelle, kosteneffiziente und zuverlässige Methode zur Erkennung von Änderungen. Leider gibt es in manchen Fällen mehr als eine echte Basis. In den meisten Repositorys ist diese Situation selten, aber in großen Repositorys mit vielen aktiven Benutzern kann sie häufiger vorkommen. Sie können manuell überprüfen, ob mehrere Mergebasen zwischen den Branches existieren. Führen Sie hierzu den Befehl git merge-base --all feature master aus. Azure DevOps erkennt die Existenz mehrerer Mergebasen für jeden PR. Wenn diese erkannt werden, zeigt Azure DevOps für den PR die folgende Nachricht an: „Mehrere Mergebasen erkannt. Die angezeigte Liste der Commits ist möglicherweise unvollständig“. Azure DevOps führt zwar die Erkennung mehrerer Mergebasen aus, überprüft aber nicht, ob die potenzielle Mergebasis bereits zusammengeführt wurde oder nicht. Diese Überprüfung wird von git merge-base durchgeführt. Aus diesem Grund kann Azure DevOps die Nachricht auch dann anzeigen, wenn git merge-base nur eine Mergebasis meldet.
Hinweis
Falls während einer PR-Überprüfung Änderungen verloren gegangen sind, vergewissern Sie sich, dass dies nicht auf mehrere Mergebasen zurückzuführen ist.
Die folgenden Szenarien werden von Azure DevOps als mehrfache Mergebasen erkannt (die Mergebasen sind durch die Nummern 1 und 2 gekennzeichnet):
- Cross-Merges (auch Criss-Cross genannt) zwischen verschiedenen Branches (von Azure DevOps ebenfalls als
git merge-basegemeldet)
---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, z. B. Ä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 Featurebranches
- Andere nicht intuitive und verworrene Manipulationen mit Wiederherstellung, Cherrypicking und Mergevorgängen.
Die Erkennung mehrerer Mergebasen 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 im Pull Request unterschiedliche Versionen zwischen den Mergebasen aufweisen, tritt eine Warnung über mehrere Mergebasen auf.
Weitere Informationen finden Sie in der offiziellen Git-Dokumentation.
Potenzielle Sicherheitsrisiken beim Mergen 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 sich die im PR vorgeschlagenen Änderungen bereits im Zielbranch befinden, werden sie auf der Registerkarte Dateien angezeigt, aber sie lösen möglicherweise keine Branchrichtlinien aus, die zu Ordneränderungen zugeordnet sind.
- Zwei Gruppen von Änderungen an denselben Dateien aus mehreren Mergebasen dürfen nicht im PR enthalten sein. Dieser Fall könnte zu tückischen Logiklücken führen.
Beheben des Problems mehrerer Mergebasen
Die Verwendung mehrerer Mergebasen 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 beseitigen die Warnmeldung und helfen Ihnen beim Überprüfen, ob die aktuellen Ä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.
Vermeiden des Problems mehrerer Mergebasen
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 Branches, die nicht direkt aus stabilen Branches Ihres Repositorys stammen, sofern dies nicht erforderlich ist.
Vorgehensweise beim erneuten Auftreten des Problems mehrerer Mergebasen
In großen Repositorys mit vielen aktiven Mitwirkenden kann dieses Problem besonders unangenehm sein. Selbst wenn Sie über einen Mergevorgang mehrere Basen beseitigen, kann die Situation erneut 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 sich nichts ändert, sind Ihre Änderungen wahrscheinlich eindeutig, auch wenn sich die Situation wiederholt.