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

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

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

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

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

Windows中的Git现在得到了很好的支持。

查看GitExtensions = http://code.google.com/p/gitextensions/

以及更好的Windows Git体验的手册。

David Richards关于Subversion / GIT的WANdisco博客

The emergence of GIT has brought with it a breed of DVCS fundamentalists – the ‘Gitterons’ – that think anything other than GIT is crap. The Gitterons seem to think software engineering happens on their own island and often forget that most organizations don’t employ senior software engineers exclusively. That’s ok but it’s not how the rest of the market thinks, and I am happy to prove it: GIT, at the last look had less than three per cent of the market while Subversion has in the region of five million users and about half of the overall market. The problem we saw was that the Gitterons were firing (cheap) shots at Subversion. Tweets like “Subversion is so [slow/crappy/restrictive/doesn't smell good/looks at me in a funny way] and now I have GIT and [everything works in my life/my wife got pregnant/I got a girlfriend after 30 years of trying/I won six times running on the blackjack table]. You get the picture.

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

我非常喜欢能够在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.