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

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

我喜欢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 GUI的人来说，Syntevo SmartGit可能是一个很好的解决方案。它是私有的，但对非商业用途是免费的，可以在Windows/Mac/Linux上运行，我认为甚至可以使用某种git-svn网桥来支持SVN。

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

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

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