我检查了一个分支，我想在master中合并。该分支落后于master，因为master在两周内没有与该分支合并，所以我想使用master中的所有更改。
我执行以下操作：
git merge -s recursive -X theirs master
在大多数情况下，它会合并，但至少有几个地方没有冲突。
例如，有一行：
#import "VMVideo_Private.h"
这是在过去两周的某些时候从主人那里取出的，但由于这个分支在过去两周没有合并，所以它仍然存在于分支机构中。
使用theirs进行合并后，它仍然存在。
此外，如果我尝试仅使用手动合并：
git merge master
这种特殊的冲突根本没有出现。
答案 0 :(得分：4)
在递归合并策略中，-X theirs（或者就此而言-X ours）只是意味着在发生冲突时它应该通过选择“他们自动解决冲突版本“（或”我们的版本“，-X ours）。
如果没有冲突，则您的-X选择根本不会发挥作用。
例如，假设在原始（通用合并基础）版本中，文件foo.txt第34行表示Rumplestiltskin。进一步假设您将其更改为George Clooney。最后，假设文件foo.txt实际上已在master中更改，但在第34行附近。现在您要求git将其（主）的更改与您的更改合并：它会保留您的更改，其中Rumplestiltskin成为克鲁尼，因为他们的变化没有冲突，foo.txt现在声称是真实的而不是虚假的。由此产生的合并现在提出关于克鲁尼先生的索赔（它声称是真的），而不是关于一个童话般的角色。
（在某些情况下，git - 只是执行各种版本的diff - 将决定你和他们对某些代码（或文本）所做的更改最好用语义上的东西表示例如，对于C和Java代码，它可能在行上错误地同步，只有一个闭括号。所得到的合并可能是搞笑的，或者悲惨的，坏的。有时选择修改后的diff算法，例如“耐心”差异“，可以帮助。有时候没有任何帮助。）
答案 1 :(得分：1)
大多数时候，你的分支被合并回来并且力量和每个分歧点的根隐藏了差异。有一个技巧可以解决它。
假设您想在执行
后从主合并到当前分支 curgit merge -s recursive -X theirs master
git commit
然后做（你必须先提交）：
git diff --ignore-space-at-eol cur..master | git apply
这只是比较合并的 cur 和 master 分支，并且差异将被拾取并作为补丁应用。