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

Question

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

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

Answer 1

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

假设项目由这些文件组成：

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

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

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

Answer 2

hgInit.com 与 Mercurial 相关，但可以很好地概述 DVCS 和 SVN 在合并冲突方面的区别。

Subversion 出问题的原因 与合并与它的方式有关 存储版本历史。颠覆 喜欢考虑修改。一种 修订版是整个文件的内容 系统看起来像一些特定的 时间点。在 Mercurial 中，您认为 关于变更集。变更集是一个 之间变化的简明清单 一个修订版和下一个修订版。

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