在合并冲突解决方面，GIT和SVN之间有什么区别

Question

我一直听说git中的分支比SVN容易得多，因为将分支合并回trunk / master更容易。我已经阅读了一些教程，但是他们只讨论了基本的合并冲突（“Alice更改了code.cpp的第8行，同时Bob更改了code.cpp的第8行......”）并且SVN和所有其他分布式源控制系统。

你能否给我一些分支中的变化示例，这些变化会导致SVN存储库出现问题，但git会优雅地处理它？<​​/ p>

Answer 1

我终于有时间修补分支/与git和svn合并，发现杀死svn但与git完美配合的情况：

假设项目包含这些文件：

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

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

SVN丢失了第3点中分支中所做的所有更改，git中的类似更改完全合并。这足以让我拒绝SVN作为任何需要分支的项目的版本控制系统。

Answer 2

hgInit.com与Mercurial有关，但会很好地概述DVCS和SVN之间在合并冲突方面的区别。

  

Subversion之所以遇到麻烦   合并与它的方式有关   存储版本历史记录。颠覆   喜欢考虑修改。一个   修改是整个文件   系统看起来有些特别   时间点。你认为在Mercurial中   关于变更集。变更集是一个   简明的列表之间的变化   一个版本和下一版本。

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