it-swarm.com.de

Wann würden Sie die verschiedenen Git-Merge-Strategien verwenden?

Auf der Manpage zu git-merge gibt es eine Reihe von Zusammenführungsstrategien, die Sie verwenden können.

  • resolve - Hiermit können nur zwei Köpfe (d. h. der aktuelle Zweig und ein anderer Zweig, aus dem Sie gezogen haben) mithilfe eines 3-Wege-Merge-Algorithmus aufgelöst werden. Es versucht, Kreuz-Kreuz-Mehrdeutigkeiten sorgfältig zu erkennen und gilt allgemein als sicher und schnell.

  • rekursiv - Dies kann nur zwei Köpfe mit dem 3-Wege-Merge-Algorithmus auflösen. Wenn es mehr als einen gemeinsamen Vorfahren gibt, der für die 3-Wege-Zusammenführung verwendet werden kann, wird ein zusammengeführter Baum der gemeinsamen Vorfahren erstellt und dieser als Referenzbaum für die 3-Wege-Zusammenführung verwendet. Es wurde berichtet, dass dies zu weniger Zusammenführungskonflikten führt, ohne dass durch Tests, die mit tatsächlichen Zusammenführungs-Commits durchgeführt wurden, die aus dem Entwicklungsverlauf des Linux 2.6-Kernels stammen, Fehlzusammenführungen verursacht werden. Außerdem können Zusammenführungen mit Umbenennungen erkannt und verarbeitet werden. Dies ist die Standard-Zusammenführungsstrategie, wenn ein Zweig gezogen oder zusammengeführt wird.

  • octopus - Dies löst mehr als zwei Fälle auf, weigert sich jedoch, komplexe Zusammenführungen durchzuführen, die manuell aufgelöst werden müssen. Es ist in erster Linie für die Bündelung von Zweigköpfen gedacht. Dies ist die Standard-Zusammenführungsstrategie, wenn mehrere Zweige gezogen oder zusammengeführt werden.

  • ours - Dies löst eine beliebige Anzahl von Köpfen auf, aber das Ergebnis der Zusammenführung ist immer der aktuelle Zweigkopf. Es soll verwendet werden, um die alte Entwicklungsgeschichte der Seitenzweige zu ersetzen.

  • Teilbaum - Dies ist eine modifizierte rekursive Strategie. Wenn beim Zusammenführen der Bäume A und B B einem Teilbaum von A entspricht, wird B zunächst an die Baumstruktur von A angepasst, anstatt die Bäume auf derselben Ebene zu lesen. Diese Anpassung wird auch am gemeinsamen Ahnenbaum vorgenommen.

Wann sollte ich etwas anderes als das Standard angeben? Welche Szenarien eignen sich jeweils am besten?

413
Otto

Ich bin nicht vertraut mit Entschlossenheit, aber ich habe die anderen verwendet:

Rekursiv

Rekursiv ist die Standardeinstellung für Zusammenführungen ohne schnellen Vorlauf. Das kennen wir alle.

Tintenfisch

Ich habe Tintenfisch verwendet, als ich mehrere Bäume hatte, die zusammengeführt werden mussten. Sie sehen dies in größeren Projekten, in denen viele Branchen unabhängig voneinander entwickelt wurden und alles in einem Kopf zusammengefasst werden kann.

Ein Octopus-Zweig fügt mehrere Köpfe zu einem Commit zusammen, sofern dies ordnungsgemäß möglich ist.

Stellen Sie sich zur Veranschaulichung vor, Sie haben ein Projekt mit einem Master und dann drei zu verschmelzenden Zweigen (nennen Sie sie a, b und c).

Eine Reihe von rekursiven Zusammenführungen würde so aussehen (beachten Sie, dass die erste Zusammenführung ein schneller Vorlauf war, da ich keine Rekursion erzwungen habe):

series of recursive merges

Eine einzelne Octopus-Zusammenführung würde jedoch so aussehen:

commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...

octopus merge

Unsere

Unseres == Ich möchte einen anderen Kopf anziehen, aber alle Änderungen, die dieser Kopf mit sich bringt, verwerfen.

Auf diese Weise wird die Geschichte eines Zweigs ohne die Auswirkungen des Zweigs gespeichert.

(Lesen Sie: Es wird nicht einmal auf die Änderungen zwischen diesen Zweigen geachtet. Die Zweige werden nur zusammengeführt und es wird nichts mit den Dateien gemacht. Wenn Sie in den anderen Zweig zusammenführen möchten und jedes Mal die Frage "Unsere Dateiversion oder deren Version "können Sie git merge -X ours)

Teilbaum

Der Unterbaum ist nützlich, wenn Sie ein anderes Projekt in einem Unterverzeichnis Ihres aktuellen Projekts zusammenführen möchten. Nützlich, wenn Sie eine Bibliothek haben, die Sie nicht als Submodul einbinden möchten.

296
Dustin

Tatsächlich sind die einzigen zwei Strategien, die Sie wählen möchten, nsere, wenn Sie Änderungen, die von einem Zweig gebracht wurden, verwerfen möchten, aber den Zweig im Verlauf behalten möchten, und Teilbaum, wenn Sie unabhängig fusionieren projiziere in das Unterverzeichnis von superproject (wie 'git-gui' im 'git'-Repository).

Das Zusammenführen von Octopus wird automatisch verwendet, wenn mehr als zwei Zweige zusammengeführt werden. Entschlossenheit ist hier hauptsächlich aus historischen Gründen und für den Fall, dass Sie von rekursiv getroffen werden Strategie-Eckfälle zusammenführen.

46
Jakub Narębski

"Resolve" vs "Recursive" Merge-Strategie

Rekursiv ist die derzeitige Standardstrategie mit zwei Köpfen, aber nach einigem Suchen fand ich endlich einige Informationen über die Zusammenführungsstrategie "Entschlossenheit".

Aus dem O'Reilly-Buch Versionskontrolle mit Git ( Amazon ) (umschrieben):

Ursprünglich war "resolve" die Standardstrategie für Git-Merges.

In Situationen mit kreuzweiser Zusammenführung, in denen es mehr als eine mögliche Zusammenführungsbasis gibt, funktioniert die Auflösungsstrategie folgendermaßen: Wählen Sie eine der möglichen Zusammenführungsbasen aus und hoffen Sie auf das Beste. Das ist eigentlich nicht so schlimm, wie es sich anhört. Es stellt sich oft heraus, dass die Benutzer an verschiedenen Teilen des Codes gearbeitet haben. In diesem Fall erkennt Git, dass einige bereits vorhandene Änderungen wiederhergestellt wurden, und überspringt die doppelten Änderungen, um den Konflikt zu vermeiden. Wenn es sich um geringfügige Änderungen handelt, die zu Konflikten führen, sollte der Konflikt zumindest für den Entwickler leicht zu handhaben sein.

Ich habe Bäume erfolgreich mit "resolve" zusammengeführt, was mit der Standard-Rekursivstrategie fehlgeschlagen ist. Ich bekam fatal: git write-tree failed to write a tree Fehler, und dank diesem Blog-Beitrag ( Spiegel ) habe ich versucht "-s aufzulösen", was funktioniert. Ich bin mir immer noch nicht ganz sicher, warum ... aber ich glaube, das lag daran, dass ich in beiden Bäumen doppelte Änderungen vorgenommen und sie ordnungsgemäß "übersprungen" habe.

21
thaddeusmt