なぜSubversionよりもDVCSの方がマージが優れているという主張は、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
ただし、リビジョンの範囲を指定するこの方法は、バージョンツリーが大きくなるとすぐに手に負えなくなります。サブバージョンには、いつどのリビジョンがマージされるかに関するメタデータがないためです。後で何が起こるかについて熟考する：
12 14
trunk …-->o-------->o
"Okay, so when did we merge last time?"
13 15
b1 …----->o-------->o
これは、Subversionが持っているリポジトリ設計による主な問題です。ブランチを作成するには、トランクのコピーを格納するリポジトリに新しい仮想ディレクトリを作成する必要がありますが、いつ、何に関する情報を保存しません。マージされた状態に戻ります。これにより、厄介なマージの競合が発生することがあります。さらに悪いことに、Subversionはデフォルトで双方向のマージを使用していたため、2つのブランチヘッドが共通の祖先と比較されない場合の自動マージにはいくつかの不自由な制限があります。
このSubversionを軽減するために、ブランチとマージのメタデータが保存されるようになりました。それですべての問題は解決しますか？
ちなみに、Subversionはまだひどい…
一元化されたシステムでは、Subversionのように、仮想ディレクトリは最低です。どうして？誰もがそれらを表示するためのアクセス権を持っているからです…ごみの実験的なものでさえです。実験したいが、全員とその叔母の実験を見たくない場合は、分岐が適しています。これは深刻な認知ノイズです。追加するブランチが多いほど、より多くのがらくたが表示されます。
リポジトリ内に公開ブランチが多いほど、さまざまなブランチすべてを追跡することが難しくなります。したがって、問題はブランチがまだ開発中であるか、集中管理されたバージョン管理システムではわかりにくいかどうかです。
ほとんどの場合、私が見た限りでは、組織はデフォルトで1つの大きなブランチを使用することになります。これは残念なことです。それは、テストやリリースのバージョンを追跡することが困難になるためです。
では、Git、Mercurial、BazaarなどのDVCSが、分岐とマージでSubversionよりも優れているのはなぜですか？
非常に単純な理由があります。分岐はファーストクラスのコンセプトです。設計上、仮想ディレクトリはなく、ブランチはDVCSのハードオブジェクトであり、リポジトリの同期（つまり、pushとpull）を単純に処理するためには、ハードオブジェクトである必要があります。
DVCSで作業するときに最初に行うことは、リポジトリ（git clone、hg clone、bzr branch）のクローンを作成することです。クローン作成は、バージョン管理でブランチを作成することと概念的に同じです。一部の人はこれをフォークまたはブランチングと呼びます（後者は同じ場所に配置されたブランチを参照するために使用されることもあります）が、それは同じことです。すべてのユーザーが独自のリポジトリを実行します。つまり、ユーザーごとのブランチが行われます。
バージョン構造はツリーではなく、グラフです。より具体的には、有向非巡回グラフ（DAG、つまりサイクルのないグラフを意味します）。各コミットに1つ以上の親参照（コミットの基になっているもの）があることを除いて、DAGの詳細を詳しく知る必要はありません。そのため、次のグラフでは、これによりリビジョン間の矢印が逆に表示されます。
マージの非常に簡単な例はこれです。と呼ばれる中央リポジトリoriginと、ユーザーのアリスが自分のマシンにリポジトリを複製するとします。
a… b… c…
origin o<---o<---o
^master
|
| clone
v
a… b… c…
alice o<---o<---o
^master
^origin/master
クローン中に発生することは、すべてのリビジョンがそれらとまったく同じように（一意に識別可能なハッシュ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
上で説明した使用例では、何もマージする必要はありません。そのため、3者間マージアルゴリズムはすべてのバージョン管理システム間でほぼ同じであるため、問題はマージアルゴリズムにはありません。問題は何よりも構造についてです。
それでは、実際にマージを行う例を教えてください。
確かに上記の例は非常に単純なユースケースなので、より一般的なものではありますが、より多くのねじれたものを実行してみましょう。origin3つのリビジョンから始まったことを覚えていますか？まあ、それらをやった人は彼を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
これで、ボブは自分の変更をoriginリポジトリに直接プッシュできなくなりました。システムがこれを検出する方法は、Bobのリビジョンがから直接下降しているかどうかをチェックすることですorigin。この場合はそうではありません。プッシュしようとすると、システムに「うーん……ボブをやらせられないのではないか」と似たような結果になります。
（gitののとボブは、インプルして、変更をマージする必要がありますのでpull、またはHGのpullとmergeまたはのbzrの; merge）。これは2段階のプロセスです。まず、ボブは新しいリビジョンを取得する必要があり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
プルプロセスの2番目のステップは、分岐するヒントをマージし、結果をコミットすることです。
v master
a… b… c… f… 1…
bob o<---o<---o<---o<-------o
^ |
| d… e… |
+----o<---o<--+
^ origin/master
うまくいけば、マージが競合に遭遇しないことを期待します（それらが予想される場合は、fetchとでgitで2つの手順を手動で実行できます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のドキュメントを読んでもらいます。
読者のための練習として、関係する別のユーザーとどのようにうまくいくかを引き出してみてください。上記の例と同様にボブを使用して行います。リポジトリ間のマージは、すべてのリビジョン/コミットが一意に識別できるため、思ったより簡単です。
また、各開発者間でパッチを送信するという問題もあります。これはSubversionで大きな問題であり、git、hg、bzrで一意に識別可能なリビジョンによって軽減されています。誰かが自分の変更をマージして（つまり、マージコミットを作成して）、中央リポジトリにプッシュするか、パッチを送信することで、チームの他の全員が使用できるように送信すると、すでに発生しているため、マージについて心配する必要はありません。 。マーティン・ファウラーは、このような無差別な統合の仕組みを呼び出しています。
Subversionとは構造が異なるため、DAGを採用することで、システムだけでなくユーザーにとっても簡単に分岐とマージを行うことができます。