Git合并 -s theirs：简单地？

Question

我已经查看了相关问题。第一个提供一篇庞大的问题回答（相关吗？不确定），而第二个提供了错误的最佳答案。

我有一个名为“great-use-this”的分支，另一个名为“master”的分支。我想将“great-use-this”合并到主分支中，并避免自动合并冲突。

什么是最简单和最容易的方法？

_{注意：我实际上已经解决了这个问题（使用第三个分支和ours），但是在SO上也需要这个信息。}

- Dan Rosenstark

---

请参见https://dev59.com/GW445IYBdhLWcg3wWI6L#4912267。 - VonC

最好展示第三个分支 + “ours”方法的示例，特别是生成的提交图，有多少噪音等。 - lkraav

@lkraav，我没有那个例子了。我现在要么用git merge BRANCH --squash做所有事情，有时候使用git reset --soft master，然后像提交新的提交一样检查。很抱歉，但如果您在另一个问题中要求一个简单的例子，那就太好了。 - Dan Rosenstark

Answer 1

是的，创建第三个分支并执行merge -s ours是一种解决方案。

但你会发现所有的"让我们不要宣传任何“theirs”合并策略"这里。

在用另一个分支替换您的工作或者仅仅摆脱当前的工作并通过另一个工作完全替换它之间，Junio C. Hamano（主要Git Maintainer）更喜欢第二种方法：

I think "-s theirs" is even worse. It is how you would discard what you did (perhaps because the other side has much better solution than your hack), but that can be much more easily and cleanly done with:

$ git reset --hard origin/master

Some people might say "But with 'merge -s theirs', I can keep what I did, too". That reset is simply discarding what I did.

That logic also is flawed. You can instead:

$ git branch i-was-stupid 
$ git reset --hard origin/master

if you really want to keep record of your failure.

One big problem "-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs".

Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you cannot offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all.

- VonC

---

逻辑上的问题是，当我合并到主分支时，这种情况就会发生。Git不能自动合并并不意味着它完全无法解决。但是我希望历史可以向前发展。无论如何，大多数这些历史记录将被重置为垃圾。 - Dan Rosenstark

适用于我的语法是 git reset --hard origin/master。 - Rian Sanderson

Answer 2

前几天遇到了这个问题：

httpx://seanius.net/blog/2011/02/git-merge-s-theirs/

更新：旧链接已失效。以下是通过Archive.org的Wayback Machine获取的文章：

git merge -s ours ref-to-be-merged
git diff --binary ref-to-be-merged | git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

- Sean Finney

---

感谢@Sean Finney，这篇文章很有趣。就我个人而言，我一直在使用reset --hard和reset --soft与引用进行大量操作，以便到达我想要的位置，这是粗暴的并且会弄乱提交历史（所以你最终会经常使用push --force :))，但是你的解决方案看起来很可靠。我很快就会去查看它。 - Dan Rosenstark

Answer 3

我更倾向于使用git reset --hard BRANCHNAME选项，但我发现在Git（v.1.7.1至少）中有一个"theirs"选项。

如果您想尝试它，只需将“-Xtheirs”参数添加到合并命令中。

例如，从主分支开始： git checkout -b editBranch
-- 编辑您的文件 --
git add .
git commit -m "更新了文件"
git checkout master
git merge -Xtheirs editBranch 如果您在editBranch中删除了任何文件，则会出现合并冲突，可以使用git rm FILENAME解决。

再次强调，似乎reset --hard BRANCHNAME是更好的选择，但如果您真的需要theirs选项，请使用上述方法。

- Alan W. Smith

---

值得强调的是，-Xtheirs 和一个假想的 -s theirs 策略完全不同。-Xtheirs 将 theirs 选项传递给递归合并策略，通过选择“theirs”版本来解决冲突块。如果像 -s ours 那样实现 -s theirs，则会选择整个“their”树而不是任何形式的智能合并。 - CB Bailey

我想我明白了。这是否意味着“-s theirs”实际上与执行“git reset --hard BRANCHNAME”是一样的？ - Alan W. Smith

@Charles Bailey，请问您对此有何评论？ - Dan Rosenstark

“-s theirs”和“-X theirs”的区别在于前者（如果仍然存在）会丢弃您所做的一切以使其与外部分支匹配。 “-X theirs”将通过选择外部分支的版本来解决冲突，但如果它们不冲突（即新文件），它仍将保留您的更改。 - SGr