为什么会使用"git merge -s ours"？

Question

据我所知,"我们的"合并策略(听到引号合并？)其实没有使用任何来自提交另一个分支.

"我们的"战略有时被称为"保持对方的历史".但它将历史记录为"应用".奇怪的.有没有我想要这种行为的情况？

作为替代方案,您也可以导入另一个分支,并将其历史记录放在那里,它所属的位置.

请注意,我问的是"-s ours"策略,而不是"-s我们的"选项"-s recursive"(不同之处在于它应用那些不冲突的提交).

Answer 1

一种用法是"跳过"在维护分支上进行的提交,该提交无意返回到开发的主/主干分支.请参阅此前一个问题的示例:git - 合并时跳过特定提交

Answer 2

简而言之：共同的祖先。

细节

每当你进行合并时，git都会找到当前分支和要合并的分支的共同祖先。然后将共同祖先之后的提交git从另一个分支合并到当前分支。

git merge -s ours 完全忽略来自其他分支的任何内容。它只是创造一个新的共同祖先。

它更改要合并的提交范围以供将来合并。

这是《Pro Git》一书中“高级合并”一章中的一个用例

例如，假设您从一个release分支中分支出来并已对其完成了一些工作，您希望master在某个时候将其合并回您的分支中。与此同时，一些错误修复master需要向后移植到您的release分支中。您可以将 bugfix 分支合并到分支中release，也可以将merge -s ours同一分支合并到您的master分支中（即使修复已经存在），这样当您稍后再次合并分支时release，bugfix 就不会产生冲突。

在此示例中，git merge -s ours用于跳过与分支中合并的错误修复提交相关的提交release。

Answer 3

另一个原因是，当您有一个与活动分支非常不同步的分支，并且希望用活动分支更新旧分支时，但是可能发生的合并冲突使得使用常规合并很容易做到这一点。

例如，我的用例是：

您有一个master和dev分支，由于某种原因，您没有在几周内更新您的master分支，并且现在尝试将dev分支合并到master分支会导致合并冲突。您可能想要做的是用dev分支的当前状态覆盖master分支，因此使两者同步。

在这种情况下，您可以执行以下操作，使用另一个SO用户在此处另一个SO答案中概述的步骤。但是，请参阅下面的警告提示。

git checkout dev
git merge -s ours master
git checkout master
git merge dev

值得一提的是：最后，我的主人与我的开发人员保持了最新联系，但是开发人员显示有4个提交要推送到远程，这很奇怪。应该推送0，因为我只是想更新master。尽管如此，代码看起来还不错。值得一提的是，由于我以前从未使用过git merge -s ours自己，因此使用率不是100％。

我还发现了另一个ours可能对人们有用的答案：https : //stackoverflow.com/a/13307342/339803