为什么在DVCS中合并比在Subversion中更好的说法主要是基于前一段时间Subversion中分支和合并的工作方式。1.5.0之前的Subversion 没有存储有关合并分支的时间的任何信息，因此，当您要合并时，您必须指定必须合并的修订范围。
那么，为什么Subversion合并很烂？
思考这个例子：
1 2 4 6 8
trunk o-->o-->o---->o---->o
\
\ 3 5 7
b1 +->o---->o---->o
当我们想要将 b1的更改合并到中继中时，当站在已检出中继的文件夹上时，发出以下命令：
svn merge -r 2:7 {link to branch b1}
…它将尝试将更改合并b1到您的本地工作目录中。然后，在解决所有冲突并测试了结果之后，提交更改。当您提交修订树时，将如下所示：
1 2 4 6 8 9
trunk o-->o-->o---->o---->o-->o "the merge commit is at r9"
\
\ 3 5 7
b1 +->o---->o---->o
但是，当版本树变大时，这种指定版本范围的方法很快就失控了，因为Subversion没有关于何时以及哪些版本合并在一起的元数据。思考以后会发生什么：
12 14
trunk …-->o-------->o
"Okay, so when did we merge last time?"
13 15
b1 …----->o-------->o
Subversion拥有的存储库设计在很大程度上是一个问题，为了创建分支，您需要在存储库中创建一个新的虚拟目录，该目录将存储主干副本，但不存储有关何时何地的任何信息。事情又重新融合了。有时会导致讨厌的合并冲突。更糟糕的是，Subversion默认情况下使用双向合并，当两个分支头未与其共同祖先进行比较时，它在自动合并方面存在一些严重的限制。
为了缓解这种情况，Subversion现在存储了用于分支和合并的元数据。那会解决所有问题吧？
哦，顺便说一句，Subversion仍然很烂……
在集中式系统（如Subversion）上，虚拟目录很烂。为什么？因为每个人都可以查看它们……甚至是垃圾实验的人。如果您想尝试，但不想看到每个人及其姨妈的实验，则分支是很好的。这是严重的认知噪音。您添加的分支越多，您看到的内容就越多。
您在存储库中拥有的公共分支越多，跟踪所有不同分支的难度就越大。因此，您将要问的问题是分支是否仍在开发中，或者它是否真的已经死了，这在任何集中式版本控制系统中都很难分辨。
从我所看到的大部分时间来看，组织将默认使用一个大分支。令人遗憾的是，这反过来将难以跟踪测试和发行版本，而分支带来的其他好处。
那么，为什么GCS，Mercurial和Bazaar等DVCS在分支和合并方面比Subversion更好？
原因很简单：分支是一流的概念。设计上没有虚拟目录，而分支是DVCS中的硬对象，为了与存储库同步（即push和pull）简单地工作，就必须如此。
使用DVCS时，要做的第一件事是克隆存储库（git clone，hg clone和bzr branch）。从概念上讲，克隆与在版本控制中创建分支相同。有人将其称为分叉或分支（尽管后者通常也用于指代共处分支），但这是同一回事。每个用户都运行自己的存储库，这意味着每个用户都在进行分支。
版本结构不是树，而是图。更具体地说，是有向无环图（DAG，表示没有任何循环的图）。除了每个提交都有一个或多个父引用（该提交所基于的父引用）以外，您实际上不需要深入研究DAG的细节。因此，下图因此将反向显示修订之间的箭头。
这是一个非常简单的合并示例。想象一个名为的中央存储库origin，一个用户Alice将存储库克隆到她的计算机上。
a… b… c…
origin o<---o<---o
^master
|
| clone
v
a… b… c…
alice o<---o<---o
^master
^origin/master
克隆期间发生的情况是，每个修订版本都被完全复制到Alice（已通过唯一可识别的hash-id进行验证），并标记了原始分支的位置。
然后，Alice在自己的存储库中工作，在自己的存储库中提交并决定推送她的更改：
a… b… c…
origin o<---o<---o
^ master
"what'll happen after a push?"
a… b… c… d… e…
alice o<---o<---o<---o<---o
^master
^origin/master
解决方案非常简单，origin存储库唯一需要做的就是获取所有新修订并将其分支移至最新修订（git称为“快进”）：
a… b… c… d… e…
origin o<---o<---o<---o<---o
^ master
a… b… c… d… e…
alice o<---o<---o<---o<---o
^master
^origin/master
我在上面说明的用例甚至不需要合并任何东西。因此，合并算法实际上不是问题，因为所有版本控制系统之间的三向合并算法几乎相同。问题更多的是结构问题。
那么，如何向我展示一个具有真实合并的示例呢？
诚然，上面的示例是一个非常简单的用例，因此尽管更常见，但让我们做的更多。还记得origin从三个修订版开始吗？好吧，做这些的人叫他Bob，他一直在自己工作，并在自己的存储库中进行了提交：
a… b… c… f…
bob o<---o<---o<---o
^ master
^ origin/master
"can Bob push his changes?"
a… b… c… d… e…
origin o<---o<---o<---o<---o
^ master
现在，Bob无法将其更改直接推送到origin存储库。系统如何通过检查Bob的修订版本是否直接从origins 下降而检测到的，在这种情况下不是这样。任何试图推动的尝试都会导致系统说出类似“ 呃...我怕不能让你那样做Bob”。
所以，鲍勃有吸合，然后合并更改（用Git的pull;或HG的pull和merge;或BZR的merge）。这是一个两步过程。首先，Bob必须获取新修订，它将从origin存储库中复制它们。现在，我们可以看到图形有所不同：
v master
a… b… c… f…
bob o<---o<---o<---o
^
| d… e…
+----o<---o
^ origin/master
a… b… c… d… e…
origin o<---o<---o<---o<---o
^ master
拉取过程的第二步是合并不同的提示并提交结果：
v master
a… b… c… f… 1…
bob o<---o<---o<---o<-------o
^ |
| d… e… |
+----o<---o<--+
^ origin/master
希望合并不会发生冲突（如果您预计会发生冲突，则可以在git中使用fetch和手动进行两个步骤merge）。以后需要做的是将这些更改再次推送到中origin，这将导致快速合并，因为合并提交是origin存储库中最新消息的直接后代：
v origin/master
v master
a… b… c… f… 1…
bob o<---o<---o<---o<-------o
^ |
| d… e… |
+----o<---o<--+
v master
a… b… c… f… 1…
origin o<---o<---o<---o<-------o
^ |
| d… e… |
+----o<---o<--+
还有另一个合并到git和hg中的选项，称为rebase，它将在最新更改之后将Bob的更改移动到。由于我不希望这个答案过于冗长，因此我将让您阅读有关git，mercurial或Bazaar的文档。
作为读者的练习，请尝试确定如何与其他相关用户一起工作。与上述Bob的示例类似。存储库之间的合并比您想象的要容易，因为所有修订/提交都是唯一可识别的。
在每个开发人员之间也存在发送补丁的问题，这在Subversion中是一个巨大的问题，可通过唯一可识别的修订版本在git，hg和bzr中缓解。一旦某人合并了他的更改（即进行合并提交）并将其发送给团队中的其他所有人，则可以通过推送到中央存储库或发送补丁来使用它，因此他们不必担心合并，因为合并已经发生了。马丁·福勒（Martin Fowler）称这种工作方式为混杂集成。
因为结构与Subversion不同，所以通过改用DAG，它不仅使系统而且对用户也使分支和合并更加容易。