其他的回答很好地解释了Git的核心特性(这些特性非常棒)。但是还有很多小方法可以让Git表现得更好，并帮助我的生活更加理智。以下是一些小细节:

Git has a 'clean' command. SVN desperately needs this command, considering how frequently it will dump extra files on your disk. Git has the 'bisect' command. It's nice. SVN creates .svn directories in every single folder (Git only creates one .git directory). Every script you write, and every grep you do, will need to be written to ignore these .svn directories. You also need an entire command ("svn export") just to get a sane copy of your files. In SVN, each file & folder can come from a different revision or branch. At first, it sounds nice to have this freedom. But what this actually means is that there is a million different ways for your local checkout to be completely screwed up. (for example, if "svn switch" fails halfway through, or if you enter a command wrong). And the worst part is: if you ever get into a situation where some of your files are coming from one place, and some of them from another, the "svn status" will tell you that everything is normal. You'll need to do "svn info" on each file/directory to discover how weird things are. If "git status" tells you that things are normal, then you can trust that things really are normal. You have to tell SVN whenever you move or delete something. Git will just figure it out. Ignore semantics are easier in Git. If you ignore a pattern (such as *.pyc), it will be ignored for all subdirectories. (But if you really want to ignore something for just one directory, you can). With SVN, it seems that there is no easy way to ignore a pattern across all subdirectories. Another item involving ignore files. Git makes it possible to have "private" ignore settings (using the file .git/info/exclude), which won't affect anyone else.

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

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).

有趣的是: 我在Subversion Repos中托管项目，但是通过Git Clone命令访问它们。

请阅读在谷歌代码项目中使用Git进行开发

虽然谷歌代码原生说话 Subversion，可以轻松使用Git 在开发过程中。搜索“git” Svn建议这种做法是正确的 广泛传播，我们也鼓励你 用它来做实验。

在Svn存储库上使用Git给我带来了好处:

我可以分配到几个 机器，承诺和从 对他们来说 我有一个中央备份/公共svn存储库供其他人检查 他们可以自由地使用Git

Subversion非常容易使用。在过去的几年里，我从来没有发现任何问题或事情没有像预期的那样工作。此外，还有许多优秀的GUI工具，对SVN集成的支持也很大。

With Git you get a more flexible VCS. You can use it the same way like SVN with a remote repository where you commit all changes. But you can also use it mostly offline and only push the changes from time to time to the remote repository. But Git is more complex and has a steeper learning curve. I found myself in the first time committing to wrong branches, creating branches indirectly or get error messages with not much informations about the mistake and where I must search with Google to get better informations. Some easy things like substitution of markers ($Id$) doesn't work but GIT has a very flexible filtering and hook mechanism to merge own scripts and so you get all things you need and more but it needs more time and reading of the documentation ;)

如果您主要脱机使用本地存储库，那么如果本地机器上丢失了某些东西，则没有备份。使用SVN，您主要使用远程存储库，同时您的备份也在另一个服务器上… Git也可以以同样的方式工作，但这并不是Linus的主要目标，要有类似SVN2的东西。它是为Linux内核开发人员和分布式版本控制系统的需要而设计的。

Git比SVN好吗?只需要一些版本历史记录和备份机制的开发人员可以轻松地使用SVN。经常使用分支、同时测试更多版本或主要离线工作的开发人员可以从Git的特性中受益。有一些非常有用的特性，比如SVN中没有的存储特性，可以使工作更轻松。但另一方面，并非所有人都需要所有功能。所以我看不到SVN的死角。

Git需要一些更好的文档，错误报告必须更有帮助。而且现有的有用的gui也很少。这次我只找到了一个支持大多数Git特性的Linux GUI (Git -cola)。Eclipse集成正在工作，但还没有正式发布，也没有官方更新站点(只有一些外部更新站点，从主干定期构建http://www.jgit.org/updates) 因此，现在使用Git的首选方式是命令行。

Subversion仍然是一种更常用的版本控制系统，这意味着它有更好的工具支持。您会发现几乎所有IDE都有成熟的SVN插件，并且有很好的资源管理器扩展可用(如TurtoiseSVN)。除此之外，我不得不同意Michael的观点:Git并不比Subversion更好或更差，它是不同的。

这里所有的答案都是意料之中的，以程序员为中心，但是如果你的公司在源代码之外使用修订控制会发生什么呢?有很多文档不是源代码，它们受益于版本控制，应该与代码接近，而不是在另一个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.