为什么Git比Subversion更好？

这是一个错误的问题。过于关注git的缺点并提出subversion在某些使用情况下显然更好的论点，这种做法太容易了。Git最初被设计为低级版本控制构造集，具有复杂的针对Linux开发人员的界面，这使得争论更容易获得支持和认可。Git支持者高唱数百万个工作流优势，而svn支持者则宣称这些优势是不必要的。很快整个辩论就被框定为中心化与分布式，这符合企业svn工具社区的利益。这些公司通常发布关于subversion在企业中卓越性的最有说服力的文章，它们依赖于git的感知不安全性以及svn的企业可用性，以确保其产品长期成功。
但是问题在于：Subversion已经成为了一种架构上的死胡同。
虽然svn已经存在了两倍以上的时间，但你可以轻松地采用git并构建一个集中式的subversion替代品。然而svn从来没有能够像git那样将基本的合并跟踪工作得如此之好。其中一个基本原因是将分支设计为与目录相同。我不知道他们最初为什么要这样做，它肯定使部分检出非常简单。不幸的是，它也使跟踪历史记录变得不可能。现在显然你应该使用subversion存储库布局约定来将分支与常规目录分开，并且svn使用一些启发式方法来使日常用例正常工作。但所有这些都只是掩盖了一个非常糟糕和限制性的低级设计决策。能够执行存储库范围的差异（而不是目录范围的差异）是版本控制系统的基本和关键功能，大大简化了内部操作，使其可以构建更智能和有用的功能。您可以看到，已经花费了大量精力扩展subversion，但在基本操作（如合并解析）方面，它仍远远落后于当前一批现代VCSes。
现在我真心诚意地给任何仍然认为Subversion足够长期使用的人提供中立的建议：
Subversion永远无法赶上从RCS和CVS中吸取教训的新一代VCS；除非他们从头开始重新设计存储库模型，但那样它就不会真正是svn了。无论您认为自己是否需要现代VCS的功能，您的无知都无法保护您免受Subversion的陷阱，其中许多情况在其他系统中是不可能或很容易解决的。
很少有技术方案如svn一样明显地落后，当然我不会对win-vs-linux或emacs-vs-vi发表这样的观点，但在这种情况下却是非常明显的。源代码控制是开发者工具包中非常基础的工具之一，无论出于组织原因使用svn的要求如何，我都希望所有使用svn的用户不要让他们的逻辑建立一个错误的信念，即更现代的版本控制系统仅对大型开源项目有用。无论你的开发工作性质如何，如果你是程序员，只要学会如何使用设计更好的版本控制系统，无论是Git、Mercurial、Darcs还是其他的，你都将成为一个更有效的程序员。

由于它不需要与中央服务器不断通信，因此几乎每个命令都可以在一秒钟内运行（显然git push / pull / fetch较慢，因为它们必须初始化SSH连接）。分支更加容易（一个简单的命令用于分支，一个简单的命令用于合并）。

对于寻找良好Git GUI的人来说，Syntevo SmartGit可能是一个不错的解决方案。虽然它是专有软件，但非商业用途免费，可在Windows/Mac/Linux上运行，并且甚至支持使用某种git-svn桥接器的SVN。

Subversion非常容易使用。在过去的几年中，我从未遇到过问题或出现预期之外的情况。此外，有许多优秀的图形用户界面工具，并且对SVN集成的支持很大。
Git是一种更灵活的版本控制系统。您可以像SVN一样使用远程存储库，在其中提交所有更改。但是，您还可以在大多数时间离线使用它，并仅在需要时将更改推送到远程存储库。 但是，Git更加复杂，并且有一个更陡峭的学习曲线。我发现自己最初将错误提交到了错误的分支，间接地创建分支或获得不太清楚的错误消息，需要用Google搜索以获取更好的信息。 一些简单的事情，如标记符号（$Id$）的替换就无法实现，但是GIT具有非常灵活的过滤和钩子机制，可以合并自己的脚本，因此您可以获得所需的一切，但它需要更多的时间和文档阅读;)
如果您大多数时间都使用本地存储库离线工作，则在本地计算机上丢失某些内容时没有备份。对于SVN而言，您主要使用远程存储库，这也是另一个服务器上的备份...... Git可以以相同的方式工作，但这不是Linus开发它的主要目的，他设计了一种分布式版本控制系统，以满足Linux内核开发人员的需求。
Git比SVN更好吗？只需要一些版本历史记录和备份机制的开发人员可以使用SVN轻松地过好生活。经常使用分支、同时测试多个版本或大多数时间离线工作的开发人员可以从Git的功能中受益。有一些非常有用的功能，例如在SVN中找不到的暂存功能，可以使生活更加轻松。但是另一方面，并不是所有人都需要所有功能。因此，我看不到SVN的终结。
Git需要更好的文档和更有帮助的错误报告。此外，现有的有用GUI很少。这次我只发现了一个支持大多数Git功能的Linux GUI（git-cola）。Eclipse集成正在工作，但它还没有正式发布，也没有官方更新站点（只有一些来自主干的周期性构建的外部更新站点http://www.jgit.org/updates）所以这些天使用Git的首选方法是使用命令行。

SourceGear的Eric Sink写了一系列关于分布式和非分布式版本控制系统之间差异的文章。他比较了最流行的版本控制系统的优缺点。非常有趣的阅读。
这些文章可以在他的博客www.ericsink.com上找到：

• 阅读Diffs

• Git是版本控制工具中的C语言

• 关于Git对不可变性的缺乏尊重和DVCS的最佳实践

• DVCS和DAG，第1部分

• DVCS和DAG，第2部分

• DVCS和Bug跟踪

• 合并历史，DAG和Darcs

• 为什么Git这么快？

• Mercurial、Subversion和Wesley Snipes

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

查看GitExtensions = http://code.google.com/p/gitextensions/以获得更好的Windows Git使用体验。

同时，阅读手册也是必不可少的。

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

我认为可以相对安全地说，在开发人员中，SVN与Git的争论已经持续了一段时间，每个人都有自己的看法。在我们2010年关于Subversion的网络研讨会中，这甚至成为了其中一个问题。

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

他还谈到了即将推出的Subversion变化，例如Working Copy Next Generation（WC-NG），他认为这将导致许多Git用户转回Subversion。

观看他的视频，并通过在此博客上发表评论或在我们的论坛上发布帖子来告诉我们您的想法。注册很简单，只需要花费一点时间！

首先，并发版本控制似乎是一个容易解决的问题。但实际上并不是这样。无论如何...

SVN相当不直观。Git更糟糕。[讽刺性推测]这可能是因为像并发版本控制这样的难题，开发人员对于制作良好的用户界面没有太多兴趣。[/讽刺性推测]

SVN支持者认为他们不需要分布式版本控制系统。我也曾这么想过。但现在我们完全使用Git，我成为了信徒。现在版本控制对我和团队/项目都起作用，而不仅仅是对项目起作用。当我需要一个分支时，我就创建一个分支。有时它是与服务器上的相应分支对应的分支，有时则不是。更不用说所有其他优点了，我将不得不去学习（部分归功于现代版本控制系统中神秘而荒谬的缺乏用户界面）。

最近我一直在使用Git，我喜欢它用于个人项目，但是考虑到员工需要改变思维方式，而且没有明显的好处，我还不能将工作项目从Subversion切换到Git。此外，我们内部运行的最大项目极度依赖svn:externals，从目前我所看到的情况来看，在Git中并不如此顺畅和无缝。

为什么我认为Subversion比Git更好（至少对于我工作的项目来说），主要是因为它的易用性和简单的工作流程：

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