首先，并发版本控制似乎是一个很容易解决的问题。一点也不。无论如何……

SVN非常不直观。Git更糟糕。这可能是因为开发人员喜欢并发版本控制这样的难题，他们对制作一个好的UI没有多大兴趣。[/ sarcastic-speculation]

SVN supporters think they don't need a distributed version-control system. I thought that too. But now that we use Git exclusively, I'm a believer. Now version control works for me AND the team/project instead of just working for the project. When I need a branch, I branch. Sometimes it's a branch that has a corresponding branch on the server, and sometimes it does not. Not to mention all the other advantages that I'll have to go study up on (thanks in part to the arcane and absurd lack of UI that is a modern version control system).

谷歌技术讲座:Linus Torvalds谈git

http://www.youtube.com/watch?v=4XpnKHJAok8

Git Wiki的比较页面

http://git.or.cz/gitwiki/GitSvnComparsion

由于它不需要不断地与中央服务器通信，几乎每个命令都在不到一秒的时间内运行(显然git的push/pull/fetch较慢，因为它们必须初始化SSH连接)。分支要容易得多(一个简单的命令就可以分支，一个简单的命令就可以合并)

我非常喜欢能够在Git中管理源代码的本地分支，而不会混淆中央存储库的水。在许多情况下，我将从Subversion服务器签出代码并运行本地Git存储库，只是为了能够做到这一点。初始化Git存储库不会因为到处都是烦人的.svn文件夹而污染文件系统，这一点也很棒。

至于Windows工具的支持，TortoiseGit处理基本的很好，但我仍然喜欢命令行，除非我想查看日志。我真的很喜欢Tortoise{Git|SVN}在读取提交日志时的帮助方式。

这里所有的答案都是意料之中的，以程序员为中心，但是如果你的公司在源代码之外使用修订控制会发生什么呢?有很多文档不是源代码，它们受益于版本控制，应该与代码接近，而不是在另一个CMS中。大多数程序员都不是孤立地工作——我们作为团队的一部分为公司工作。

考虑到这一点，比较Subversion和git在客户端工具和培训方面的易用性。我看不出有哪一种分布式修订控制系统会更容易使用或向非程序员解释。我很乐意被证明是错误的，因为这样我就可以评估git，并希望它能够被那些需要版本控制的人(而不是程序员)接受。

即便如此，如果管理层问我为什么我们应该从集中式版本控制系统转向分布式版本控制系统，我也很难给出一个诚实的答案，因为我们不需要它。

Disclaimer: I became interested in Subversion early on (around v0.29) so obviously I'm biased, but the companies I've worked for since that time are benefiting from my enthusiasm because I've encouraged and supported its use. I suspect this is how it happens with most software companies. With so many programmers jumping on the git bandwagon, I wonder how many companies are going to miss out on the benefits of using version control outside of source code? Even if you have separate systems for different teams, you're missing out on some of the benefits, such as (unified) issue tracking integration, whilst increasing maintenance, hardware and training requirements.

Git并不比Subversion好。但也不是更糟。这是不一样的。

关键的区别在于它是去中心化的。想象一下你是一个在路上的开发人员，你在你的笔记本电脑上开发，你想要有源代码控制，这样你就可以回到3小时前。

使用Subversion时，您会遇到一个问题:SVN存储库可能位于您无法到达的位置(在您的公司中，并且您目前没有互联网)，您无法提交。如果你想复制你的代码，你必须复制/粘贴它。

使用Git，您就不会遇到这个问题。您的本地副本是一个存储库，您可以提交它并获得源代码控制的所有好处。当您重新获得到主存储库的连接时，您可以针对它提交。

一开始看起来不错，但是要记住这种方法增加了复杂性。

Git似乎是“新的、闪亮的、酷的”东西。它绝对不坏(毕竟Linus为Linux内核开发写了它是有原因的)，但是我觉得很多人只是因为它是新的并且是由Linus Torvalds写的，就跳上了“分布式源代码控制”这列火车，而不知道为什么/它是否更好。

Subversion有问题，但是Git、Mercurial、CVS、TFS等等也有问题。

编辑:所以这个答案现在已经有一年了，仍然获得了很多赞，所以我想我会添加更多的解释。在写这篇文章后的去年，Git获得了很多动力和支持，特别是在像GitHub这样的网站真正起飞之后。我现在同时使用Git和Subversion，我想分享一些个人见解。

First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "git init" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.

当你去中心化的时候，Git真的会发光。我家里有一台服务器，路上有一台笔记本电脑，SVN在这里根本不能很好地工作。使用SVN，如果我没有连接到存储库，我就不能进行本地源代码控制(是的，我知道SVK或复制回购的方法)。对于Git，这是默认模式。这是一个额外的命令(git commit在本地提交，而git push origin master将主分支推到名为“origin”的远程)。

如上所述:Git增加了复杂性。创建存储库的两种模式，签出vs克隆，提交vs推…您必须知道哪些命令在本地工作，哪些命令在“服务器”上工作(我假设大多数人仍然喜欢中央的“主存储库”)。

而且，工具仍然不够，至少在Windows上是这样。是的，有一个Visual Studio插件，但我仍然使用git bash和msysgit。

SVN的优点是学习起来简单得多:有您的存储库，所有针对它的更改，如果您知道如何创建、提交和签出，您就可以准备好，并可以在以后提取分支、更新等内容。

Git的优势在于，如果一些开发人员不总是连接到主存储库，它会更适合。而且，它比SVN快得多。据我所知，分支和合并支持要好得多(这是意料之中的，因为这是编写它的核心原因)。

这也解释了为什么它在互联网上获得了如此多的关注，因为Git非常适合开源项目:只需Fork它，将您的更改提交到您自己的Fork，然后让原始项目维护者提取您的更改。使用Git，这就可以了。真的，在Github上试试吧，太神奇了。

我还看到了Git-SVN网桥:中央存储库是一个Subversion repo，但开发人员在本地使用Git，网桥将他们的更改推到SVN。

但是即使有了这么长的补充，我仍然坚持我的核心信息:Git并没有更好或更差，它只是不同而已。如果你需要“离线源代码控制”，并愿意花一些额外的时间学习它，那就太棒了。但是如果您有一个严格集中的源代码控制，并且/或者因为您的同事不感兴趣而在第一时间努力引入源代码控制，那么SVN的简单性和出色的工具(至少在Windows上)就会脱颖而出。