Gibt es eine "ihre" Version von "git merge -s our"?

Wenn git mergeich den Themenzweig "B" mit "A" zusammenführe, treten Konflikte auf. Ich weiß, dass alle Konflikte mit der Version in "B" gelöst werden können.

Ich bin mir bewusst git merge -s ours. Aber was ich will, ist so etwas wie git merge -s theirs.

Warum existiert es nicht? Wie kann ich nach der widersprüchlichen Zusammenführung mit vorhandenen gitBefehlen das gleiche Ergebnis erzielen ? ( git checkoutjede nicht zusammengeführte Datei von B)

UPDATE: Die "Lösung", nur etwas aus Zweig A (dem Merge-Commit-Punkt zur B-Version des Baums) zu verwerfen, ist nicht das, wonach ich suche.

Fügen Sie die -XOption hinzu theirs. Zum Beispiel:

git checkout branchA
git merge -X theirs branchB

Alles wird auf die gewünschte Weise zusammengeführt.

Ich habe nur Probleme gesehen, wenn Dateien aus branchB gelöscht wurden. Sie erscheinen als Konflikte, wenn etwas anderes als Git die Entfernung durchgeführt hat.

Die Lösung ist einfach. Führen Sie einfach git rmden Namen aller gelöschten Dateien aus:

git rm {DELETED-FILE-NAME}

Danach -X theirssollte das wie erwartet funktionieren.

Das eigentliche Entfernen mit dem git rmBefehl verhindert natürlich, dass der Konflikt überhaupt erst auftritt.

Hinweis : Es gibt auch eine längere Formularoption.

Um es zu verwenden, ersetzen Sie:

-X theirs

mit:

--strategy-option=theirs

Eine mögliche und getestete Lösung zum Zusammenführen von branchB mit unserem ausgecheckten branchA:

# in case branchA is not our current branch
git checkout branchA

# make merge commit but without conflicts!!
# the contents of 'ours' will be discarded later
git merge -s ours branchB    

# make temporary branch to merged commit
git branch branchTEMP         

# get contents of working tree and index to the one of branchB
git reset --hard branchB

# reset to our merged commit but 
# keep contents of working tree and index
git reset --soft branchTEMP

# change the contents of the merged commit
# with the contents of branchB
git commit --amend

# get rid off our temporary branch
git branch -D branchTEMP

# verify that the merge commit contains only contents of branchB
git diff HEAD branchB

Um es zu automatisieren, können Sie es mit branchA und branchB als Argumenten in ein Skript einbinden.

Diese Lösung behält das erste und zweite übergeordnete Element des Zusammenführungs-Commits bei, genau wie Sie es erwarten würden git merge -s theirs branchB.

In älteren Versionen von git konnten Sie die Zusammenführungsstrategie "ihrer" verwenden:

git pull --strategy=theirs remote_branch

Dies wurde jedoch inzwischen entfernt, wie in dieser Nachricht von Junio ​​Hamano (dem Git-Betreuer) erläutert . Wie im Link angegeben, würden Sie stattdessen Folgendes tun:

git fetch origin
git reset --hard origin

Beachten Sie jedoch, dass dies anders ist als eine tatsächliche Zusammenführung. Ihre Lösung ist wahrscheinlich die Option, nach der Sie wirklich suchen.

Es ist nicht ganz klar, was Ihr gewünschtes Ergebnis ist, daher gibt es einige Verwirrung über die "richtige" Vorgehensweise in den Antworten und ihren Kommentaren. Ich versuche einen Überblick zu geben und sehe die folgenden drei Optionen:

Versuchen Sie, B zusammenzuführen und B für Konflikte zu verwenden

Dies ist nicht die "ihre Version für git merge -s ours", sondern die "ihre Version für git merge -X ours" (kurz für git merge -s recursive -X ours):

git checkout branchA
# also uses -s recursive implicitly
git merge -X theirs branchB

Dies ist, was zB die Antwort von Alan W. Smith tut.

Verwenden Sie nur Inhalte von B.

Dadurch wird ein Zusammenführungs-Commit für beide Zweige erstellt, alle Änderungen werden jedoch verworfen branchAund nur der Inhalt wird beibehalten branchB.

# Get the content you want to keep.
# If you want to keep branchB at the current commit, you can add --detached,
# else it will be advanced to the merge commit in the next step.
git checkout branchB

# Do the merge an keep current (our) content from branchB we just checked out.
git merge -s ours branchA

# Set branchA to current commit and check it out.
git checkout -B branchA

Beachten Sie, dass bei der Zusammenführung das erste übergeordnete Element jetzt das von branchBund nur das zweite von ist branchA. Dies ist, was zB die Antwort von Gandalf458 tut.

Verwenden Sie nur Inhalte von B und behalten Sie die korrekte übergeordnete Reihenfolge bei

Dies ist die echte "ihre Version für git merge -s ours". Es hat den gleichen Inhalt wie in der vorherigen Option (dh nur den von branchB), aber die Reihenfolge der Eltern ist korrekt, dh der erste Elternteil kommt von branchAund der zweite von branchB.

git checkout branchA

# Do a merge commit. The content of this commit does not matter,
# so use a strategy that never fails.
# Note: This advances branchA.
git merge -s ours branchB

# Change working tree and index to desired content.
# --detach ensures branchB will not move when doing the reset in the next step.
git checkout --detach branchB

# Move HEAD to branchA without changing contents of working tree and index.
git reset --soft branchA

# 'attach' HEAD to branchA.
# This ensures branchA will move when doing 'commit --amend'.
git checkout branchA

# Change content of merge commit to current index (i.e. content of branchB).
git commit --amend -C HEAD

Dies ist die Antwort von Paul Pladijs (ohne dass eine vorübergehende Verzweigung erforderlich ist).

Ich habe seitdem die Antwort von Paul Pladijs verwendet. Ich habe herausgefunden, dass Sie eine "normale" Zusammenführung durchführen können, Konflikte auftreten, also tun Sie es

git checkout --theirs <file>

um den Konflikt mithilfe der Revision aus dem anderen Zweig zu lösen. Wenn Sie dies für jede Datei tun, haben Sie das gleiche Verhalten, das Sie erwarten würden

git merge <branch> -s theirs

Auf jeden Fall ist der Aufwand größer als bei der Merge-Strategie! (Dies wurde mit Git Version 1.8.0 getestet)

Ich habe mein Problem mit gelöst

git checkout -m old
git checkout -b new B
git merge -s ours old

Beim Zusammenführen des Themenzweigs "B" in "A" mit Git Merge treten einige Konflikte auf. Ich weiß, dass alle Konflikte mit der Version in "B" gelöst werden können.

Ich bin mir unserer Zusammenführung bewusst. Aber was ich will, ist so etwas wie Git Merge.

Ich gehe davon aus, dass Sie einen Zweig von Master erstellt haben und nun wieder zu Master verschmelzen möchten, um alle alten Dinge in Master zu überschreiben. Genau das wollte ich tun, als ich auf diesen Beitrag stieß.

Tun Sie genau das, was Sie tun möchten, außer dass Sie zuerst den einen Zweig in den anderen zusammenführen. Ich habe das einfach gemacht und es hat großartig funktioniert.

git checkout Branch
git merge master -s ours

Dann checkout master und füge deinen Zweig darin zusammen (es wird jetzt reibungslos gehen):

git checkout master
git merge Branch

Wenn Sie sich in Zweig A befinden, tun Sie Folgendes:

git merge -s recursive -X theirs B

Getestet auf Git Version 1.7.8

Um eine Zusammenführung wirklich richtig durchzuführen, die nur Eingaben von dem Zweig enthält, den Sie zusammenführen, können Sie dies tun

git merge --strategy=ours ref-to-be-merged

git diff --binary ref-to-be-merged | git apply --reverse --index

git commit --amend

In keinem mir bekannten Szenario gibt es Konflikte, Sie müssen keine zusätzlichen Zweige erstellen und es verhält sich wie ein normales Zusammenführungs-Commit.

Dies spielt jedoch mit Submodulen nicht gut.

Warum existiert es nicht?

Während ich in " git-Befehl zum Erstellen eines Zweigs wie eines anderen " erwähne, wie simuliert werden soll git merge -s theirs, ist zu beachten, dass Git 2.15 (Q4 2017) jetzt klarer ist:

Die Dokumentation für ' -X<option>' für Zusammenführungen wurde irreführend geschrieben, um darauf hinzuweisen, dass " -s theirs" existiert, was nicht der Fall ist.

Siehe Commit c25d98b (25. September 2017) von Junio ​​C Hamano ( gitster) .
^{(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit 4da3e23 , 28. September 2017)}

Zusammenführungsstrategien: Vermeiden Sie, dass " -s theirs" existiert

Die Beschreibung der -XoursZusammenführungsoption enthält eine Anmerkung in Klammern, die den Lesern mitteilt, dass sie sich stark von -s oursder korrekten unterscheidet. Die Beschreibung -Xtheirsfolgt jedoch nachlässig: "Dies ist das Gegenteil von ours", was einen falschen Eindruck vermittelt, den die Leser ebenfalls benötigen gewarnt zu werden, dass es sich sehr von dem unterscheidet -s theirs, was in Wirklichkeit gar nicht existiert.

-Xtheirsist eine Strategieoption, die auf eine rekursive Strategie angewendet wird. Dies bedeutet, dass die rekursive Strategie immer noch alles zusammenführt, was sie kann, und nur theirsim Falle von Konflikten auf die Logik zurückgreift .

Diese Debatte über die Relevanz oder Nicht-Relevanz einer theirsFusionsstrategie wurde kürzlich in diesem Thread vom September 2017 zurückgebracht .
Es erkennt ältere (2008) Threads an

Kurz gesagt, die vorherige Diskussion kann zu "Wir wollen nicht" zusammengefasst werden -s theirs, da dies den falschen Workflow fördert.

Es erwähnt den Alias:

mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

Jaroslaw Halchenko versucht erneut, sich für diese Strategie einzusetzen, aber Junio ​​C. Hamano fügt hinzu :

Der Grund, warum unsere und ihre nicht symmetrisch sind, ist, dass Sie Sie sind und nicht sie - die Kontrolle und das Eigentum an unserer Geschichte und ihrer Geschichte ist nicht symmetrisch.

Sobald Sie entschieden haben, dass ihre Historie die Hauptlinie ist, möchten Sie Ihre Entwicklungslinie lieber als Nebenzweig behandeln und eine Zusammenführung in diese Richtung vornehmen, dh das erste übergeordnete Element der resultierenden Zusammenführung ist eine Festschreibung für ihre Historie und die zweite Eltern sind die letzten schlechten in Ihrer Geschichte. Sie würden also " checkout their-history && merge -s ours your-history" verwenden, um die Erstelternschaft vernünftig zu halten.

Und zu diesem Zeitpunkt ist die Verwendung von " -s ours" keine Problemumgehung mehr, da " -s theirs" fehlt .
Es ist ein angemessener Teil der gewünschten Semantik, dh aus der Sicht der überlebenden kanonischen Geschichtslinie möchten Sie das, was sie getan hat, beibehalten und das, was die andere Geschichtslinie getan hat, zunichte machen .

Junio ​​fügt hinzu, wie von Mike Beaton kommentiert :

git merge -s ours <their-ref>effektiv sagt "Mark Commits, die in <their-ref>ihrem Zweig gemacht wurden, als Commits, die dauerhaft ignoriert werden sollen";
und dies ist wichtig, denn wenn Sie später aus späteren Zuständen ihres Zweigs zusammenführen, werden deren spätere Änderungen übernommen, ohne dass die ignorierten Änderungen jemals übernommen werden .

Siehe Junio ​​Hamanos häufig zitierte Antwort : Wenn Sie festgeschriebene Inhalte verwerfen möchten, verwerfen Sie einfach die Festschreibungen oder halten Sie sie auf jeden Fall aus der Hauptgeschichte heraus. Warum sollte man in Zukunft alle belästigen, Commit-Nachrichten von Commits zu lesen, die nichts zu bieten haben?

Aber manchmal gibt es administrative Anforderungen oder vielleicht einen anderen Grund. Für Situationen, in denen Sie wirklich Commits aufzeichnen müssen, die nichts beitragen, möchten Sie:

(edit: wow, habe ich es geschafft, das vorher falsch zu verstehen. Dieses funktioniert.)

git update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard

Dieser verwendet einen Lesebaum für den Git-Installationsbefehl, sorgt jedoch für einen kürzeren Gesamtworkflow.

git checkout <base-branch>

git merge --no-commit -s ours <their-branch>
git read-tree -u --reset <their-branch>
git commit

# Check your work!
git diff <their-branch>

Dadurch wird Ihre neue Branche in der vorhandenen Basisbranche zusammengeführt

git checkout <baseBranch> // this will checkout baseBranch
git merge -s ours <newBranch> // this will simple merge newBranch in baseBranch
git rm -rf . // this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch

Ich denke, was Sie eigentlich wollen, ist:

git checkout -B mergeBranch branchB
git merge -s ours branchA
git checkout branchA
git merge mergeBranch
git branch -D mergeBranch

Das scheint ungeschickt, aber es sollte funktionieren. Der einzige Gedanke, den ich an dieser Lösung wirklich nicht mag, ist, dass der Git-Verlauf verwirrend sein wird ... Aber zumindest bleibt der Verlauf vollständig erhalten und Sie müssen für gelöschte Dateien nichts Besonderes tun.

Das Äquivalent (das die übergeordnete Reihenfolge beibehält) zu 'git merge -s itss branchB'

Vor dem Zusammenführen:

!!! Stellen Sie sicher, dass Sie in einem sauberen Zustand sind !!!

Führen Sie die Zusammenführung durch:

git commit-tree -m "take theirs" -p HEAD -p branchB 'branchB^{tree}'
git reset --hard 36daf519952 # is the output of the prev command

Was wir gemacht haben ? Wir haben ein neues Commit erstellt, das zwei Eltern von uns und von ihnen haben, und das Contnet des Commits ist branchB - von ihnen

Nach dem Zusammenführen:

Etwas präziser:

git commit-tree -m "take theirs" -p HEAD -p 'SOURCE^{commit}' 'SOURCE^{tree}'

Diese Antwort wurde von Paul Pladijs gegeben. Ich habe nur seine Befehle angenommen und der Einfachheit halber einen Git-Alias ​​erstellt.

Bearbeiten Sie Ihre .gitconfig und fügen Sie Folgendes hinzu:

[alias]
    mergetheirs = "!git merge -s ours \"$1\" && git branch temp_THEIRS && git reset --hard \"$1\" && git reset --soft temp_THEIRS && git commit --amend && git branch -D temp_THEIRS"

Dann können Sie "git merge -s its A" ausführen, indem Sie Folgendes ausführen:

git checkout B (optional, just making sure we're on branch B)
git mergetheirs A

Ich musste dies erst kürzlich für zwei separate Repositorys tun, die einen gemeinsamen Verlauf haben. Ich begann mit:

• Org/repository1 master
• Org/repository2 master

Ich wollte, dass alle Änderungen von repository2 masterangewendet werden, repository1 masterund akzeptierte alle Änderungen, die Repository2 vornehmen würde. In gits Worten sollte dies eine Strategie sein, die -s theirsABER nicht existiert. Seien Sie vorsichtig, denn der -X theirsName lautet so, wie Sie es möchten, aber er ist NICHT derselbe (auf der Manpage steht dies sogar).

Ich habe das gelöst, indem repository2ich zu einem neuen Zweig gegangen bin repo1-merge. In diesem Zweig bin ich gelaufen git pull git@gitlab.com:Org/repository1 -s oursund es geht ohne Probleme gut zusammen. Ich schiebe es dann auf die Fernbedienung.

Dann gehe ich zurück zu repository1und mache einen neuen Zweig repo2-merge. In diesem Zweig führe ich aus, git pull git@gitlab.com:Org/repository2 repo1-mergewas mit Problemen abgeschlossen wird.

Schließlich müssten Sie entweder eine Zusammenführungsanforderung ausgeben repository1, um sie zum neuen Master zu machen, oder sie einfach als Zweig behalten.

Eine einfache und intuitive (meiner Meinung nach) zweistufige Methode ist dies

git checkout branchB .
git commit -m "Picked up the content from branchB"

gefolgt von

git merge -s ours branchB

(was die beiden Zweige als zusammengeführt markiert)

Der einzige Nachteil ist, dass keine Dateien entfernt werden, die in Zweig B aus Ihrem aktuellen Zweig gelöscht wurden. Ein einfacher Unterschied zwischen den beiden Zweigen zeigt anschließend an, ob solche Dateien vorhanden sind.

Dieser Ansatz macht auch aus dem späteren Revisionsprotokoll deutlich, was getan wurde - und was beabsichtigt war.