从历史上看，Subversion只能执行直接的双向合并，因为它没有存储任何合并信息。这涉及到获取一组更改并将它们应用到树中。即使使用合并信息，这仍然是最常用的合并策略。

默认情况下，Git使用3-way合并算法，其中包括为合并的头部找到一个共同的祖先，并利用合并两侧存在的知识。这使得Git在避免冲突方面更加智能。

Git还有一些复杂的重命名查找代码，这也有帮助。它不存储更改集或存储任何跟踪信息——它只存储每次提交时的文件状态，并根据需要使用启发式方法定位重命名和代码移动(磁盘上的存储比这更复杂，但它呈现给逻辑层的接口没有暴露跟踪)。

SVN跟踪文件，Git跟踪内容变化。跟踪从一个类/文件重构到另一个类/文件的代码块是足够聪明的。他们使用两种完全不同的方法来追踪你的来源。

我仍然大量使用SVN，但我对我使用Git的几次非常满意。

如果你有时间，这是一本不错的书:为什么我选择Git

从历史上看，Subversion只能执行直接的双向合并，因为它没有存储任何合并信息。这涉及到获取一组更改并将它们应用到树中。即使使用合并信息，这仍然是最常用的合并策略。

默认情况下，Git使用3-way合并算法，其中包括为合并的头部找到一个共同的祖先，并利用合并两侧存在的知识。这使得Git在避免冲突方面更加智能。

Git还有一些复杂的重命名查找代码，这也有帮助。它不存储更改集或存储任何跟踪信息——它只存储每次提交时的文件状态，并根据需要使用启发式方法定位重命名和代码移动(磁盘上的存储比这更复杂，但它呈现给逻辑层的接口没有暴露跟踪)。

One thing that hasn't been mentioned in the other answers, and that really is a big advantage of a DVCS, is that you can commit locally before you push your changes. In SVN, when I had some change I wanted to check in, and someone had already done a commit on the same branch in the meantime, this meant that I had to do an svn update before I could commit. This means that my changes, and the changes from the other person are now mixed together, and there is no way to abort the merge (like with git reset or hg update -C), because there is no commit to go back to. If the merge is non-trivial,this means that you can't continue to work on your feature before you have cleaned up the merge result.

但是，也许这只是那些太笨而不能使用单独分支的人的优势(如果我没记错的话，在我使用SVN的公司中，我们只有一个用于开发的分支)。

刚读了Joel博客上的一篇文章(很遗憾是他的最后一篇)。这篇文章是关于Mercurial的，但实际上它谈论的是分布式VC系统(如Git)的优势。

使用分布式版本控制， 分布式部分实际上不是 最有趣的部分。有趣的是，这些系统从变化的角度考虑问题，而不是从版本的角度。

点击这里阅读文章。

编辑:这主要是解决这部分问题: 这实际上是由于两个系统工作方式的内在差异，还是特定的DVCS实现(如Git/Mercurial)具有比SVN更聪明的合并算法? TL;DR——那些特定的工具有更好的算法。分布式有一些工作流的好处，但与合并的好处是正交的。 最后编辑

我读了公认的答案。这是完全错误的。

SVN合并可能是一件痛苦的事情，而且可能很麻烦。但是，先忽略它是如何工作的。没有什么信息是Git保留或可以导出的，而SVN不能保留或不能导出。更重要的是，保持版本控制系统的独立副本(有时是部分副本)没有理由为您提供更多实际信息。这两种结构完全相同。

假设你想做Git“更擅长”的“一些聪明的事情”。你的东西已经登记到SVN了。

将SVN转换为等效的Git表单，在Git中完成，然后在一些额外的分支中检查结果(可能使用多次提交)。如果您能想象出一种将SVN问题转化为Git问题的自动化方法，那么Git就没有根本优势。

在一天结束的时候，任何版本控制系统都会让我

1. Generate a set of objects at a given branch/revision.
2. Provide the difference between a parent child branch/revisions.

此外，对于合并，了解它也是有用的(或关键的)

3. The set of changes have been merged into a given branch/revision.

Mercurial, Git和Subversion(现在是本地的，以前使用svnmerge.py)都可以提供所有这三条信息。为了证明DVC从根本上更好，请指出在Git/Mercurial/DVC中可用而在SVN /集中式VC中不可用的第四点信息。

这并不是说它们不是更好的工具!