GIT和SVN在解决合并冲突方面有哪些区别？

Question

我经常听说在git中分支比在SVN中容易得多，因为更容易将分支合并回主干/主线。我读了一些教程，但它们只涵盖了基本的合并冲突（“Alice更改了code.cpp的第8行，同时Bob更改了code.cpp的第8行...”），而且在SVN和所有其他分布式源代码控制系统之间没有区别。

你能否举出在SVN存储库中会引起麻烦的分支更改示例，但是在git中会被优雅地处理的例子？

- chalup

---

这看起来与此问题非常相似：https://dev59.com/EnE95IYBdhLWcg3wDpqg，因此您可能需要查看一下。 - welp

也许 SVN 最近有更新？我不知道，我很少使用它。SVN 能够持续地从远程分支合并吗？ - hasen

Answer 1

我最近有些时间研究了git和svn的分支/合并功能，并发现了一个能够使svn出错但是在git中运行完美的案例:

假设这个项目由以下文件组成:

/main.cpp
/sub1/sub1.cpp
/sub1/sub1.h

1. 创建分支。
2. 在主干中，将 sub1.* 移动到根目录下，并删除 sub1 子目录。
3. 在分支中 /sub1/sub1.cpp 进行一些更改。
4. 在主干中 /sub1.cpp 进行一些更改。
5. 合并分支和主干。

SVN 在第三步中丢失了分支中所做的所有更改，而类似的更改在 Git 中可以很好地合并。这足以让我拒绝使用 SVN 作为需要分支的任何项目的版本控制系统。

- chalup

Answer 2

hgInit.com 与 Mercurial 相关，但可以很好地介绍 DVCS 和 SVN 在合并冲突方面的差异。

Subversion 难以进行合并的原因在于它存储版本历史的方式。Subversion 喜欢考虑修订版。修订版是某个特定时间点上整个文件系统的样子。而在 Mercurial 中，你需要考虑变更集。变更集是一份简明的列表，列出了一个修订版和下一个修订版之间的变更。

因此，在合并时，Subversion 比较整个文件，而 Mercurial（或 Git）单独比较每个变更集。处理变更集时冲突发生的频率要少得多。

- Benjamin Ortuzar

---

哦？我只看到了我问题中描述的基本冲突情况。 - chalup