为什么要使用“git merge -s ours”？答案

【问题标题】：Why would one use "git merge -s ours"?为什么要使用“git merge -s ours”？
【发布时间】：2011-02-22 11:49:09
【问题描述】：

我了解“我们的”合并策略（听到 merge 周围的引号？）实际上不使用来自其他分支的任何提交。

“我们的”策略有时被称为“保留对方的历史”。但它将该历史记录为“已应用”。奇怪的。 在某些情况下我确实想要这种行为吗？

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

请注意，我问的是“-s ours”策略，而不是“-s recursive”的“-X ours”选项（不同之处在于它应用了那些不冲突的提交）。

【问题讨论】：

虽然很晚：看看here

标签： git merge

【解决方案1】：

一种用途是“跳过”在维护分支上所做的提交，该提交不打算返回到开发的主/主干分支。有关示例，请参见上一个问题：git - skipping specific commits when merging

【讨论】：

【解决方案2】：

另一个原因是当您有一个与活动分支非常不同步的分支时，您希望用活动分支更新旧分支，但可能的合并冲突会阻止通过正常合并轻松完成此操作。

例如，我的用例是：

您有一个 master 和 dev 分支，由于某种原因，您已经数周没有更新您的 master 分支，并且您尝试将您的 dev 分支合并到 master 现在会导致合并冲突。你可能想要做的是用你的 dev 分支的当前状态覆盖你的 master 分支，所以让它们同步。

在这种情况下，您可以使用其他 SO 用户 in another SO answer here 概述的步骤执行以下操作。 但请参阅下面的警告说明。

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

【讨论】：

【解决方案3】：

简而言之：共同祖先。

详情

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

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

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

Here's a use case in the "Advanced Merging" chapter from the book Pro Git

例如，假设您从一个 release 分支分支出来，并且已经完成了一些工作，您希望在某个时候合并回您的 master 分支。与此同时，master 上的一些错误修复需要向后移植 到您的release 分支中。您可以将错误修复分支合并到 release 分支，也可以将同一分支合并到 master 分支（即使修复已经存在），所以当您稍后再次合并 release 分支时，没有来自错误修复的冲突。

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

【讨论】：

【解决方案4】：

我在一个额外的分支中使用了这个伪合并，用于跟踪其他分支，包括废弃的分支。这个额外的分支实际上只有一个文件（称为branches-list），其中包含活动和非活动分支的文本列表，但在重要点（主要是分支点和“分支结束”，合并或放弃）开发分支被合并（用“-s ours”）到这个分支。

这是our project最近的截图：

因此，我最后从 master 分支了 elo-test，然后从这里我分支了 stroke-transform-example 为我的 question here（答案 - 这应该是两个不同的提交，不过）。在每个这样的分支点，更重要的是，在分支结束而没有合并到其他分支的每个点（下次清理时stroke-transform-example 会发生这种情况），我现在将此分支与-s ours 合并到元分支branches。

然后我可以稍后删除不再使用的分支而不会丢失它们的历史记录，因此git branch -a 的输出总是很小。如果我想回头看看我当时的所作所为，我可以很容易地找到它们。

（我认为这并不是这个选项的真正用途，但它的效果非常好。）

【讨论】：

感谢您的说明性回答。在 *merge -sours" 之后，区分这个“伪”合并和“真正的合并”需要查看差异，我说对了吗？
btw&ot，我想我会偶尔试试这个link（用纸和铅笔）！
是的，你是对的。在我的例子中，我只在branches 分支上使用这些伪合并，所以很容易看到。 -- 这个游戏在电脑支持下更容易玩，因为你不应该看到对手的隐藏点。随意看看我们的节目，它可以免费在线玩:-)

【解决方案5】：

另一种用途是作为强制推送的替代方案，不会对其他人造成非快进更改。

例如你想恢复一个传入的（愚蠢的）提交，但你不想做git push -f，因为那样你将花费接下来的半小时指导你的客户从中恢复，并且你想要一个更短的替代方案

git checkout -b temp remote/origin
git revert HEAD
git push temp:origin
git checkout master
git merge origin/master

所以你只需这样做

git merge -s ours origin/master

【讨论】：

【解决方案6】：

这样做的一个用途是为另一次合并做准备。

假设您有一些下游更改想要与新的上游版本合并，但新的上游版本不是旧上游版本的 git 后代（可能是因为旧的上游版本是一个已经分歧的稳定分支来自主干，可能是因为上游版本实际上是导入工具的结果）。

你能做的是。

查看新的上游版本。
“psuedomerge”旧的上游版本。
合并新的下游版本。

这样你的本地更改将被合并，但 git 不会尝试合并旧的上游更改，因为它认为它们已经合并。

【讨论】：