我了解“ours”合并策略(注意在merge周围的引号)实际上不使用来自其他分支的任何提交。
“ours”策略有时被提到为“保留其他历史记录”。但是它将该历史记录记录为“已应用”。很奇怪。 是否存在我需要此行为的情况?
作为替代,您可以导入其他分支并将其历史记录保留在原位。
请注意,我询问的是“-s ours”策略,而不是“-s recursive”选项的“-X ours”选项(它不同之处在于应用那些不冲突的提交)。
一个用途是“跳过”在维护分支上进行的提交,这些提交不打算回到您的主干/开发分支中。参考此先前的问题作为示例:git - skipping specific commits when merging
另一个原因是当你有一个分支与你的活动分支非常不同步,且你希望用活动分支更新旧分支,但可能的合并冲突使得使用普通合并难以实现。
例如,我的使用情况是:
你有一个主分支和一个开发分支,由于某种原因,你已经几周没有更新过主分支了,而现在尝试将开发分支合并到主分支中会出现合并冲突。你可能想要做的是用当前开发分支的状态覆盖主分支,以使它们保持同步。
在这种情况下,你可以按照另一位SO用户在此处的另一个SO答案所述的步骤进行操作。但请注意我的警告说明。
git checkout dev
git merge -s ours master
git checkout master
git merge dev
简短说明一下:最后,我的主分支已经更新到了我的开发分支的最新版本,但开发分支却显示有4个提交需要推送到远程仓库,这很奇怪。应该不需要推送任何内容,因为我只是想要更新主分支。尽管如此,代码似乎没有问题。需要注意的是,在此之前我从未使用过git merge -s ours
命令,所以我对它的用法不是100%确定。
我还发现另一个使用ours
选项的答案可能对人们有用:https://stackoverflow.com/a/13307342/339803
每当您执行合并操作时,git
将查找当前分支和要合并的分支的共同祖先。然后,git
将把另一个分支共同祖先之后的提交合并到当前分支中。
git merge -s ours
完全忽略来自另一个分支的任何内容。它只是创建一个新的共同祖先。
它更改了将来合并的提交范围。
以下链接是来自《Pro Git》书籍“高级合并”章节的一个应用案例
例如,假设您从
release
分支进行了分支,并对其进行了一些工作,稍后需要将其合并回master
分支。与此同时,master
上的某个错误修复需要被反向移植到您的release
分支中。您可以将错误修复分支合并到release
分支中,并在将来将release
分支再次合并时,通过将同一分支与您的master
分支进行merge -s ours
来跳过与错误修复提交相关的提交,即使修复已经存在,则没有冲突。
在此示例中,git merge -s ours
被用于跳过与release
分支合并的错误修复提交。
branches-list
),其中包含活跃和不活跃分支的文本列表,但在重要的点(大多数分支点和“分支结束”,无论是合并还是废弃)开发分支被合并(用“-s ours”)到这个分支中。elo-test
分支,然后从这个分支又创建了stroke-transform-example
分支用于我的问题(以及答案 - 尽管这应该是两个不同的提交)。在每个这样的分支点上,更重要的是,在每个分支结束时,如果它没有合并到其他分支中(当我下次清理时会发生在stroke-transform-example
上),我现在将这个分支与元分支branches
合并,并使用-s ours
选项。git branch -a
命令的输出始终很小。如果我想回顾一下我当时做的事情,我可以很容易地找到它们。(我认为这不是这个选项的真正用途,但它的效果非常好。)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