2010-02-15 5 views
23

Ich habe ein kleines Problem. Wir haben ein eigenes CMS, das git für Collaboration und Versioning verwendet.git merge rekursiv, wie funktioniert es?

Jetzt habe ich zwei Git-Repositories A und B, A ist ein Projekt und B ist das CMS selbst. Jetzt mag ich B in A zu bekommen, aber wenn ich dies tun bekomme ich eine Menge von Konflikten beim Zusammenführen und die Lösung für die Konflikte ist immer das Zeug von B. zu verwenden

Nun, was ich denke, ich brauche, ist

git merge <branch> -s recursive theirs <commit> 

Ich möchte zusammenführen und wenn es einen Zusammenführungskonflikt gibt, sollte es gezwungen werden, die Lösung von B zu verwenden. Aber ich kann es nicht zum Funktionieren bringen. Es sagt mir immer wieder fatal: 'theirs' does not point to a commit.

Die recursive theirs Ich fand here.

Weiß jemand, was ich falsch mache?

+0

Mögliches Duplikat [Wie wähle ich eine (?) Merge-Strategie für eine Git-Rebase?] (http://stackoverflow.com/questions/2945344/how-do-i-select-a-merge-strategy-for-a-gi-rebase) – Louis

Antwort

48

Sie müssen dieses Formular verwenden, um merge Strategie Optionen übergeben:

git merge -s recursive -Xtheirs 

Auch Ihre Version suppors stellen Sie sicher, -Xtheirs, das ist ein ganz letztes Merkmal

+0

es war in der Tat der falsche Git Version, jetzt mit der neuen es funktioniert .. nur funktioniert es nicht so gut wie ich dachte, ich bekomme alle Zusammenführungskonflikte, aber keine von ihnen enthalten Konflikte: s –

+0

Diese Antwort scheint die Einbeziehung der Branche in die Zusammenführung zu verpassen? 'git merge -s rekursiv -Xtheirs ' – robstarbuck

2

Ich denke, der Grund dafür ist, dass Sie "rekursive ihre" als Strategie angeben. "rekursiv" ist eine Strategie, und wenn Sie ein Leerzeichen dahinter setzen, wird "ihres" als etwas interpretiert, mit dem Ihre Arbeitskopie zusammengeführt werden muss (zB ein anderer Zweig oder refspec).

Ich denke, dass Sie nicht in der Lage sein werden, eine Strategie genau so zu spezifizieren, wie Sie wollen. Es gibt eine Strategie namens "unsere", die das Gegenteil von dem ist, was Sie wollen.

Das übliche Muster, das in dieser Situation verwendet wird, besteht darin, das Repository "B" entweder zusammenzuführen oder neu zu erstellen. Innerhalb der Arbeitskopie des "A" -Registers würden Sie, wenn möglich, eine Rebase durchführen (dies ist möglicherweise nicht möglich, wenn Sie das Git-Repository bereits mit anderen Entwicklern teilen). Eine Rebase würde das A-Repository im Wesentlichen zu einem gemeinsamen Commit in beiden Repositories zurückrollen, "B" -Commits anwenden und dann "A" oben festschreiben. Sie würden alle Zusammenführungskonflikte auf dem Weg lösen.

Sobald Sie durch den Schmerz der Verschmelzung oder Rebasing auf die "B" Repository gehen, werden die zukünftigen Zusammenführungen weniger schmerzhaft sein.