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

Question

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

“我们的”战略有时被称为“保持对方的历史”。但它将历史记录为“应用”。奇怪的。 是否存在我确实需要此行为的情况？

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

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

Answer 1

一种用法是“跳过”在维护分支上进行的提交，该提交无意返回到开发的主/主干分支。有关示例，请参阅此前一个问题：git - skipping specific commits when merging

Answer 2

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

例如，我的用例是：

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

在这种情况下，您可以使用其他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

Answer 3

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

最近的our project屏幕截图：

因此，我最后从master中分支elo-test，然后从此我为question here分支stroke-transform-example（答案 - 这应该是两个不同的提交）。在每个这样的分支点，更重要的是，在分支结束时的每一点，没有它被合并到其他分支（当我下次清理时将发生stroke-transform-example），我现在将此分支与{ {1}}到元分支-s ours。

然后我可以在不丢失历史记录的情况下删除未使用的分支，因此branches的输出总是非常小。 如果我想再回顾一下我的所作所为，我很容易找到它们。

（我认为这不是真正的选择，但它的效果非常好。）

Answer 4

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

E.g。你想要恢复传入（愚蠢）提交，但你不想做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

Answer 5

这方面的一个用途是作为另一次合并的准备。

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

你能做的是。

1. 查看新的上游版本。
2. ＆＃34; psuedomerge＆＃34;旧的上游版本。
3. 合并新的下游版本。

通过这种方式，您的本地更改将被合并，但是git不会尝试合并旧的上游更改，因为它认为它们已经合并。

Answer 6

简而言之：共同祖先。

详细信息

无论何时进行合并，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分支中。您可以将bugfix分支合并到release分支中，也可以将merge -s ours的同一分支合并到master分支中（即使已存在此修复程序），因此当以后合并{{1 }}再次分支，没有来自错误修正的冲突。

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