git的合并冲突解决方案比其他SCM和合并工具更有效吗？

Question

git合并冲突解决方案本身是否比其他SCM(CVS,Subversion等)以及独立的合并工具更有效率？如果是这样,为什么？

澄清:这里我对算法本身更感兴趣 - 它与普通的diff3方法有什么不同？
一些工具声称更聪明(例如Guiffy),是否值得插入作为git合并工具？git是否更聪明地找出在文件内或跨文件移动的文本？(而不是报告嘈杂的冲突..我对Linus的谈话有一种模糊的印象).

背景:刚刚做了一个巨大的合并使用git-svn,导致了一半的冲突比我得到的普通svn merge(第一次合并没有跟踪)..所以我想了解原因.

---

类似的Qs/As周围,但它们更多的是关于过程的大局,以及合并如何更自然地适应.为此,git"优化合并"(而不仅仅是分支),它实际上意味着:

1. 减少手动冲突 - 更好的自动分辨率算法(例如,重命名处理得很好)
2. 更安全的操作 - 自动解决更多/只有真正的冲突和更少的错误警报
3. 更快的操作 - 比如,由于精益和平均对象模型
4. 更好的工具 - 这使得体验减少痛苦,例如基于DAG的合并跟踪,合并工具,历史查询/可视化,藏匿,变基等...
5. 别的
6. 以上的组合

？现在,我最感兴趣的是1和2.

Answer 1

我很想在这个答案上被证明是错误的，但是……来自于必然……git 的这个领域还有些欠发达。

1. git 中不存在自动合并。最新版本具有使用您的更改或他们的更改执行合并的基本支持，但仅此而已。基本上，如果您编辑文件的一部分，而其他人编辑文件的同一部分……您就需要自己进行合并解析。diff3 格式可用（3 路合并），但我相信统一的 diff 格式是标准。我实际上使用 araxis 作为合并工具，并将其设置为在运行“git mergetool”时使用 3 路合并。不过，我觉得 git 在这个领域远远落后。

2. 不适用

更新回复：评论

我还没有足够深入地了解 git 所认为的冲突和 p4 所认为的冲突，但这是我在两者中所经历的。

• Git 在进行合并时不会忽略空格...尽管将来会有关于 git 的讨论。p4 现在可以做到这一点。不忽略空白是一个很大的痛苦，除非团队中的每个人都同意使用空格或制表符，并且如果您想更改文件的缩进......（例如在其他节点周围添加 xml 节点）那么这很快就会过时。
• 我觉得当我遇到文件中的合并冲突时...... git 说使用其统一差异格式发生冲突的部分更大。当只有一行的一部分发生更改时，它会将较大的部分标记为已修改，并且您需要直观地查找统一差异输出的两个区域之间的更改。不过，您可以使用合并工具来解决这个问题。即使编辑同一行，p4 也能够自动解决冲突。
• 如果您要合并长期存在的主题分支，那么您将获得真正的享受。如果不打开 rerere（默认情况下关闭），git 会忘记您已经合并了一周前发生冲突的文件，并会要求您再次合并它。p4 轻松做到这一点

我在这里的答案有点主观......但我非常怀念我与 perforce 的合并。