SVN和Git之间的合并有什么区别？

Question

正如标题所示，我很好奇为什么有这么多人吹嘘Git作为分支/合并SVN的优秀替代品。我主要是好奇，因为SVN合并很糟糕，我想要一个替代解决方案。

Git如何更好地处理合并？它是如何工作的？

例如，在SVN中，如果我有以下行：

Hello World！

然后user1将其更改为：

Hello World！1

然后user2将其更改为：

Hello World！12

然后user2提交，然后user1提交，SVN会给你一个冲突。 Git可以解决这个简单的问题吗？

Answer 1

在与冲突合并时调用它，并且VCS不会为你解决这个问题 您必须自己手动解决合并。

如Why merging in git is better than SVN中所述，实际差异在于提交的历史记录：

• 线性SVN
• DAG (Directed Acyclic Graph) for Git

这允许Git记住已经合并的内容，大大减少了冲突的发生。

  

因此，当需要从5b合并到（a）分支时，我们可以使用DAG中的信息来知道3b和2b已经完成

---

因此， merge workflow Git将比SVN更优雅地处理： 有关具体示例，请参阅Merge Git vs. SVN。

Answer 2

您提到的具体冲突是总是无法解决。合并工具根本无法知道应该保留哪个版本。

但是，在处理可解决的冲突时，Git可能比SVN更好。它的主要合并策略是递归的，它找到了两个提交的共同祖先，它们改变了同一个文件并进行了三向合并。它还具有一些内置功能，可以记录和重用冲突解决方案（git-rerere）以及针对特殊情况的各种其他merge strategies。

Git在合并方面的优势在于它是历史的一部分。合并提交是具有两个父项的提交。 Git的历史模型（有向无环图）预计会有这样的提交。这意味着未来的进一步合并将如何应对。总是。 （是的，有时会发生冲突，但它们是真正的冲突，而不是无法处理合并。）

另一方面，SVN只是试图跟踪合并发生的位置，但其模型本质上仍然是线性的。历史记录仍然只有一个提交字符串，合并跟踪信息提供额外的帮助。据我所知，SVN无法始终正确处理更复杂的合并模式。 （一个例子是反射合并 - 将A合并为B，然后将B合并为A。）