当我在分支之间合并时，git会对冲突进行递归合并，并放入<<<<<<< Temporary merge branch x块。这有点令人讨厌，导致25个冲突需要在kdiff3中进行人工干预。
然后我做了一个git merge-base，只返回一个SHA1（如果你能帮我理解原因，请参阅my other question。）
如果我使用该提交中的代码作为基础在kdiff3中手动构建3向合并，则它更简单，只需要手动解决2个直接冲突。
有没有办法可以使用标准的git命令来完成这项工作，而不必为文件手动建立我自己的合并？
答案 0 :(得分：1)
[从the other question移回来，现在这个问题又回来了:-) ......我只留下一个链接，而不是完全删除那个答案。]
它有些笨拙，但您可以在手动提取所需的基本，本地和其他文件版本后运行the git merge-file command。这给了你最多的控制权，我认为如果Git提供一个小帮助程序来运行它可能会很好。
有git checkout -m，但请参见下文。
也就是说，我们应该能够做到：
git merge --no-commit <args>
然后无论我们得到什么样的状态，包括像已经安装了＆＃34;虚拟合并基础的递归合并这样的icky案例＆＃34;作为索引中的共同基础，我们应该能够做到：
git re-merge [options] <path>
默认情况下会从当前索引中提取base，local和other，并重新尝试合并。
此默认值与git checkout -m -- <path>完全相同，那么为什么这个建议的助手会有用呢？良好：
请注意，git checkout也可以--ours（使用本地解析）和--theirs（使用其他解析）。这个建议的命令将有--our s / --local和--theirs / --other，这将提取这些版本但不像git checkout，不是标记冲突已解决。
这里的想法是，如果冲突尚未标记为已解决，您可以方便地查看git diff输出。
它会--union（git merge-file也有，git checkout没有）。联合合并很少有用，但在 有用的极少数情况下，让计算机执行此操作肯定会很好。
以下是此特定案例的关键项：它可以通过某种方式指定基础。例如，--base <tree-ish> [--basepath <path>]将忽略索引的基本blob并从给定的<tree-ish>获取基数。默认<path>将与当前目录中的文件相同，因此我们需要一种方法来解决重命名案例。这是--basepath会做的，或者<tree-ish>可能只是<tree-ish-or-blob>，以便--base HEAD~15:path/to/different/name有效。
这又是git merge-file的一个小包装器。它的主要优点是允许您不必知道如何从索引中提取blob，制作一堆临时文件，然后清理这些临时文件。此外，因为它永远不会解决任何事情（与git checkout不同），它会感觉不那么最终＆＃34;，或者至少它对我有用。