你对“自动解决的冲突”和“增量”的区分是没有意义的/不存在的。
这里只存在“自动解决的冲突”和“未自动解决的冲突”。注意，由于不同的算法，普通git和KDiff 3之间的更改集合是不同的。与普通git相比，KDiff 3在接受接近的更改而不放弃方面更具“侵略性”，尽管在过去的几年中差异已经缩小，以前差别更大。
尽管如此，git将某些内容标记为无法自动解决的冲突并不罕见，只有KDiff 3在作为difftool启动时（或通过我的git-resolve-conflict-using-kdiff3脚本）声明没有未解决的冲突。
因此，自动解析的不是一门精确的科学，而是启发式算法，它可以执行change over time。即使自动解析，这也只是git/KDiff 3的猜测，绝对没有办法保证结果是正确的。
请考虑以下合并冲突示例：

在手动正确地将函数签名解析为static void hello(unsigned int count, const char *message)（这是唯一没有自动解决的冲突）之后，结果仍然不正确，因为函数goodbye包含对hello的调用，该调用只有一个参数，并且没有更新为包含新的count参数。
所以你不能依赖于自动解决的冲突是正确的，不管你多么希望它是真的。是的，这意味着你应该审查所有的更改，即使它“永远需要你”。
现在，您可以做一些事情来证明在KDiff 3中进行更轻松/更快速的审查是合理的。

• 退出KDiff 3后使用git diff --cached（或可能的git diff -U10 --cached）查看。
• 对分支上的所有提交运行git test来验证完整性/正确性，特别是在变基之后。