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

Question

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

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

例如,在SVN中,如果我有以下行:

你好,世界!

然后user1将其更改为:

Hello World!1

然后user2将其更改为:

Hello World!12

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

Answer 1

这被称为合并冲突,没有VCS会为你解决这个问题.
您必须自己手动解决合并.

正如为什么合并git比SVN更好,实际差异在于提交的历史记录:

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

DAG

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

因此,合并工作流程 Git将比SVN更优雅地处理:
请参阅合并Git与SVN的具体示例.

Answer 2

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

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

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

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