合并期间发生冲突。该文件包含一些已正确合并代码的区域以及一个在HEAD（我们的）和要合并的分支（它们的）之间进行选择的区域。我想接受冲突的成功合并区域和HEAD部分。
可以在命令行上完成吗？
如果我做
git merge -s ours incomingbranch
它似乎没有合并文件。它只是用当前分支的（我们的）版本替换文件。
如果我做
git merge incomingbranch
git checkout --ours path/to/conflict/file
它似乎也用当前分支的（我们的）版本替换了文件。
我想要的是一种自动修复冲突区域并保留合并部分的工具。
显然，简单的方法是
git merge incomingbranch
(edit the conflictedfile and remove the relevant conflict chunks)
git add conflictedfile
git commit -m "fixed"
但我正在寻找一个命令行选项，最好对单个文件执行此操作。
Git的选项在这里有点令人困惑。
-sGit合并的标志设置合并策略。该策略负责获取所有要合并的提交，并弄清楚如何合并它们：要从哪些提交中使用哪些文件，如何合并其内容，等等。在实际情况下，用户实际上只应该选择两种策略：-s ours，您发现它意味着完全忽略其他提交，默认策略-s recursive是您想要不同的行为。1个
但是除了-s旗帜，还有-X旗帜。Git的调用参数-X“战略选择”（见的git merge文档），但我想打电话给他们扩展选项，都因为有它的字母X，因为他们的工作扩展到战略。因此，您可能想要的是-X ours。这与有很大的不同-s ours！您仍在使用-s recursive，只是在告诉递归策略，如果发生冲突，它应该自动选择HEAD端。
那不是很你想要什么，这是因为：
最好用于单个文件
...-X ours适用于所有文件级合并冲突。2
要获得所需的内容，您需要允许发生合并冲突，然后：
使用三个暂存槽中的文件的三个副本将该文件的所有三个输入提取到工作树中，以便您可以查看和处理它们。
git merge-file使用--ours选项在三个文件上运行。
将已解析的文件放到适当的位置，并使用git add它来将其复制到索引暂存插槽零中，从而清除步骤1中使用的插槽1-3中的三个副本。
要完全了解第1步，请参阅其他SO发布信息（我现在没有时间找到它）并考虑使用git checkout-index --stage=all。请参阅该git checkout-index文档的详细信息。
1有第三个策略，-s resolve当存在多个合并库时，其作用不同。普通用户从来没有真正需要过-s resolve。当您合并两个以上提交时，Git有一个章鱼策略可以单独使用。Git专家用户可能会使用章鱼策略，但是当他们运行正确的时会自动发生git merge，因此他们实际上并不需要此-s选项。
2我将形容词文件级别放在这里，因为它们是低级别的，在一个文件内的冲突。Git还具有高级冲突，例如，在合并的一侧修改或重命名文件，而另一侧只是完全删除文件时，就会发生高级冲突。扩展选项，-s resolve从不解决任何高级冲突；它们只会影响这些低级冲突。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句