我喜欢Git，因为它实际上有助于在中大型团队中开发人员之间的沟通。作为一个分布式版本控制系统，通过它的推送/拉系统，它帮助开发人员创建一个源代码生态系统，这有助于管理在单个项目上工作的大量开发人员。

例如，假设你信任5个开发人员，并且只从他们的存储库中提取代码。每个开发人员都有自己的信任网络，从那里提取代码。因此，开发是基于开发人员之间的信任结构，其中代码责任由开发社区共享。

当然，在这里的其他答案中也提到了其他好处。

This is the wrong question to be asking. It's all too easy to focus on git's warts and formulate an argument about why subversion is ostensibly better, at least for some use cases. The fact that git was originally designed as a low-level version control construction set and has a baroque linux-developer-oriented interface makes it easier for the holy wars to gain traction and perceived legitimacy. Git proponents bang the drum with millions of workflow advantages, which svn guys proclaim unnecessary. Pretty soon the whole debate is framed as centralized vs distributed, which serves the interests of the enterprise svn tool community. These companies, which typically put out the most convincing articles about subversion's superiority in the enterprise, are dependent on the perceived insecurity of git and the enterprise-readiness of svn for the long-term success of their products.

但问题是:Subversion是架构的死胡同。

Whereas you can take git and build a centralized subversion replacement quite easily, despite being around for more than twice as long svn has never been able to get even basic merge-tracking working anywhere near as well as it does in git. One basic reason for this is the design decision to make branches the same as directories. I don't know why they went this way originally, it certainly makes partial checkouts very simple. Unfortunately it also makes it impossible to track history properly. Now obviously you are supposed to use subversion repository layout conventions to separate branches from regular directories, and svn uses some heuristics to make things work for the daily use cases. But all this is just papering over a very poor and limiting low-level design decision. Being able to a do a repository-wise diff (rather than directory-wise diff) is basic and critical functionality for a version control system, and greatly simplifies the internals, making it possible to build smarter and useful features on top of it. You can see in the amount of effort that has been put into extending subversion, and yet how far behind it is from the current crop of modern VCSes in terms of fundamental operations like merge resolution.

现在，对于那些仍然相信Subversion在可预见的未来足够优秀的人，我有一个发自内心的不可知论的建议:

Subversion永远不会赶上从RCS和CVS的错误中吸取教训的新型vcs;这在技术上是不可能的，除非他们从头开始重新配置存储库模型，但这样就不是真正的SVN了，不是吗?不管你认为自己有多不具备现代VCS的能力，你的无知也无法保护你远离Subversion的陷阱，其中许多情况在其他系统中是不可能或很容易解决的。

It is extremely rare that the technical inferiority of a solution is so clear-cut as it is with svn, certainly I would never state such an opinion about win-vs-linux or emacs-vs-vi, but in this case it is so clearcut, and source control is such a fundamental tool in the developer's arsenal, that I feel it must be stated unequivocally. Regardless of the requirement to use svn for organizational reasons, I implore all svn users not to let their logical mind construct a false belief that more modern VCSes are only useful for large open-source projects. Regardless of the nature of your development work, if you are a programmer, you will be a more effective programmer if you learn how to use better-designed VCSes, whether it be Git, Mercurial, Darcs, or many others.

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上)就会脱颖而出。

我喜欢Git，因为它实际上有助于在中大型团队中开发人员之间的沟通。作为一个分布式版本控制系统，通过它的推送/拉系统，它帮助开发人员创建一个源代码生态系统，这有助于管理在单个项目上工作的大量开发人员。

例如，假设你信任5个开发人员，并且只从他们的存储库中提取代码。每个开发人员都有自己的信任网络，从那里提取代码。因此，开发是基于开发人员之间的信任结构，其中代码责任由开发社区共享。

当然，在这里的其他答案中也提到了其他好处。

为什么我认为Subversion比Git好(至少对于我所从事的项目来说)，主要是因为它的可用性和更简单的工作流程:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

http://subversion.wandisco.com/component/content/article/1/40.html

我认为可以很有把握地说，在开发人员中，SVN和Git的争论已经激烈了一段时间，每个人都有自己的观点，哪个更好。这甚至在我们2010年及以后关于颠覆的网络研讨会的问题中被提出。

我们的开源和Subversion公司总统总监Hyrum Wright谈到了Subversion和Git之间的区别，以及其他分布式版本控制系统(DVCS)。

他还谈到了Subversion中即将发生的变化，比如下一代工作拷贝(WC-NG)，他认为这会导致许多Git用户转换回Subversion。

请观看他的视频，并通过在这个博客上评论或在我们的论坛上发帖来告诉我们你的想法。注册很简单，只需要一点时间!