Git和DVCS通常都非常适合于独立编写大量代码的开发人员，因为每个人都有自己的分支。但是，如果您需要从其他人那里进行更改，她必须提交给她的本地回购，然后她必须将该更改集推给您，或者您必须从她那里获取更改集。

我自己的推理也让我认为，如果你做集中发布之类的事情，DVCS会让QA和发布管理变得更加困难。必须有人负责从其他人的存储库中进行推送/拉取，解决任何在最初提交时就可以解决的冲突，然后进行构建，然后让所有其他开发人员重新同步他们的回购。

当然，所有这些都可以通过人工流程来解决;DVCS只是破坏了一些由集中式版本控制修复的东西，以便提供一些新的便利。

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的首选方式是命令行。

Easy Git有一个很好的页面，比较了Git和SVN的实际使用情况，这将让你了解Git可以做什么(或更容易做什么)。(从技术上讲，这是基于Easy Git的，它是Git之上的轻量级包装器。)

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.

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

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

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

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

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

谷歌技术讲座:Linus Torvalds谈git

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

Git Wiki的比较页面

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