7.8 节Git 工具-高级合并-其他类型的合并-我们的或他们的偏好-最后一段对 ours 解释模糊

[devLiuGit]

现在的版本:

当再次合并时从本质上欺骗 Git 认为那个分支已经合并过经常是很有用的。 例如，假设你有一个分叉的 release 分支并且在上面做了一些你想要在未来某个时候合并回 master 的工作。 与此同时 master 分支上的某些 bugfix 需要向后移植回 release 分支。 你可以合并 bugfix 分支进入 release 分支同时也 merge -s ours 合并进入你的 master 分支 （即使那个修复已经在那儿了）这样当你之后再次合并 release 分支时，就不会有来自 bugfix 的冲突。

修改后容易理解的版本:

如果在合并操作中要跳过某个提交, 并在稍后要继续进行合并操作, 诱使Git认为分支已经合并通常是有帮助的. 假设你分出了一个名为release的分支, 在该分支上完成了一些工作, 希望之后将release分支合并回master分支. 在此之间, 在master分支上进行的一些bug修复工作需要向后移植到release分支, 你可以将master分支合并入release分支. 随后, 如果master分支有一个提交A的内容不想合并到release分支, 但是在这个提交A之后的还未出现的bug修复预计会继续合并到release分支, 这时可以使用merge -s ours将master合并入release分支.

参考资料:

progit/progit2#426
英文版也有很多人不理解在讲什么

stackoverflow 上对 ours 使用场景解释比较全面的回答
https://stackoverflow.com/questions/5077688/why-would-one-use-git-merge-s-ours
https://stackoverflow.com/questions/727994/git-skipping-specific-commits-when-merging/729723

[networm]

可以提交一个 PR