我已经使用Subversion几年了，使用SourceSafe之后，我只是喜欢Subversion。与TortoiseSVN结合使用，我真的无法想象它会变得更好。
但是，越来越多的开发人员声称Subversion存在问题，我们应该转向新的分布式版本控制系统，例如Git。
Git在Subversion上有何改进？
我已经使用Subversion几年了，使用SourceSafe之后，我只是喜欢Subversion。与TortoiseSVN结合使用，我真的无法想象它会变得更好。
但是，越来越多的开发人员声称Subversion存在问题，我们应该转向新的分布式版本控制系统，例如Git。
Git在Subversion上有何改进？
Answers:
Git并不比Subversion好。但是也不差。这是不同的。
关键区别在于它是分散的。想象一下，您是旅途中的开发人员，您在笔记本电脑上进行开发，并且希望拥有源代码控制权，因此可以返回3小时。
使用Subversion，您会遇到一个问题：SVN信息库可能位于您无法访问的位置（在公司中，并且您目前没有互联网），因此无法提交。如果要复制代码，则必须逐字复制/粘贴。
使用Git，您就不会遇到这个问题。您的本地副本是一个存储库，您可以对其进行提交并获得源代码管理的所有好处。重新获得与主存储库的连接时，可以对其进行提交。
首先看起来不错，但请记住此方法会增加复杂性。
Git似乎是“新的，闪亮的，酷的”东西。这绝不是一件坏事（毕竟，Linus为Linux Kernel开发编写了它是有原因的），但是我感到很多人跳入“分布式源代码控制”培训只是因为它是新的，并且是由Linus Torvalds编写的，实际上没有知道为什么/如果更好。
Subversion有问题，但是Git，Mercurial，CVS，TFS或其他问题也有问题。
编辑：所以这个答案已经有一年历史了，仍然产生了很多反对意见，所以我想我会添加一些更多的解释。自编写此书以来的最后一年，Git获得了很多动力和支持，尤其是自GitHub之类的网站真正腾飞以来。如今，我同时使用Git和Subversion，并希望分享一些个人见解。
首先，当分散工作时，Git最初可能真的会造成混乱。什么是遥控器？以及如何正确设置初始存储库？一开始会出现两个问题，特别是与SVN的简单“ svnadmin create”相比，Git的“ git init”可以采用--bare和--shared参数，这似乎是设置集中式管理的“正确”方法资料库。这是有原因的，但是会增加复杂性。“ checkout”命令的文档对于转换的人非常混乱-“正确”的方式似乎是“ git clone”，而“ git checkout”似乎是切换分支。
当您分散时，Git确实会发光。我在家中有一台服务器，在旅途中有一台笔记本电脑，而SVN在这里根本无法正常工作。使用SVN，如果未连接到存储库，则无法获得本地源代码控制（是的，我知道SVK或复制存储库的方式）。无论如何，使用Git都是默认模式。不过，这是一个额外的命令（git commit在本地提交，而git push origin master将master分支推送到名为“ origin”的远程）。
如上所述：Git增加了复杂性。创建存储库的两种模式，检出vs.克隆，提交vs.推送...您必须知道哪些命令在本地工作以及哪些命令与“服务器”一起工作（我假设大多数人仍然喜欢中央的“主存储库” ）。
而且，该工具仍然不足，至少在Windows上是如此。是的，有一个Visual Studio插件，但是我仍然将git bash与msysgit一起使用。
SVN的优点是学习起来非常简单：存在您的存储库，对它的所有更改，如果您知道如何创建，提交和签出，并且准备就绪，可以稍后进行分支，更新等操作上。
Git的优点是，如果某些开发人员不总是连接到主存储库，则它更适合。而且，它比SVN快得多。从我听到的信息来看，分支和合并支持要好得多（这是可以预期的，因为这是编写它的核心原因）。
这也解释了为什么它在Internet上获得如此多的关注，因为Git非常适合开放源代码项目：只需将它分叉，将您的更改提交到您自己的Fork中，然后要求原始项目维护者撤消您的更改。使用Git，这是可行的。真的，在Github上尝试一下，这很神奇。
我还看到的是Git-SVN桥：中央存储库是Subversion存储库，但是开发人员在本地使用Git进行工作，然后桥将其更改推送到SVN。
但是即使有这么长的时间，我仍然坚持我的核心信息：Git并不好坏，只是有所不同。如果您需要“离线源代码管理”，并且愿意花一些额外的时间来学习它，那就太好了。但是，如果您有严格集中化的Source Control，并且/或者由于您的同事不感兴趣而一开始就在努力引入Source Control，那么SVN的简单性和出色的工具（至少在Windows上如此）非常出色。
使用Git，您几乎可以脱机执行任何操作，因为每个人都有自己的存储库。
制作分支和分支之间的合并真的很容易。
即使您没有项目的提交权限，您仍然可以在线拥有自己的存储库，并为补丁发布“推送请求”。每个喜欢您的补丁程序的人都可以将其加入他们的项目中，包括官方维护人员。
派生一个项目，对其进行修改，并且仍然继续合并来自HEAD分支的错误修正，这是微不足道的。
Git为Linux内核开发人员工作。这意味着它确实非常快（必须如此），并且可以扩展到成千上万的贡献者。Git还使用较少的空间（Mozilla存储库的空间最多减少30倍）。
Git非常灵活，而且非常TIMTOWTDI（有多种方法可以做到）。您可以使用所需的任何工作流程，而Git将支持它。
最后，还有GitHub，这是一个托管Git存储库的好网站。
Git的缺点：
其他答案也很好地解释了Git的核心功能（很棒）。但是，还有很多小方法可以使Git表现得更好，并帮助保持我的生活更加理智。以下是一些小事情：
git mv和git rm。
“ 为什么Git比X更好 ”概述了Git与其他SCM的优缺点。
简要地：
有一些缺点：
在最简单的用法中，Subversion和Git几乎相同。之间没有太大区别：
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
和
git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
Git真正令人眼前一亮的是分支并与其他人一起工作。
好吧，它是分布式的。基准测试表明它的速度要快得多（考虑到它的分布式特性，差异和日志之类的操作都是本地的，因此在这种情况下当然要快得多），并且工作文件夹更小（这仍然让我震惊）。
当您使用Subversion或任何其他客户端/服务器版本控制系统时，实际上是通过签出修订版本在计算机上创建工作副本。这代表了存储库外观的快照。您通过更新来更新工作副本，并通过提交来更新存储库。
使用分布式版本控制，您没有快照，而只有整个代码库。想要与3个月大的版本进行比较吗？没问题，使用3个月的旧版本仍在您的计算机上。这不仅意味着事情要快得多，而且如果您与中央服务器断开连接，您仍然可以执行许多惯用的操作。换句话说，您不仅拥有给定修订版的快照，而且还拥有整个代码库。
您可能会认为Git会占用您的硬盘驱动器上的大量空间，但是从我所看到的一些基准测试来看，它实际上花费的空间更少。不要问我如何。我的意思是，它是由Linus构建的，我对文件系统了解一两点。
我喜欢DVCS的要点是：
进行相对大型项目的主要原因是第3点改善了沟通。其他都是不错的奖励。
有趣的是：我在Subversion Repos中托管项目，但是通过Git Clone命令访问它们。
尽管Google Code的母语是Subversion，但是您可以在开发过程中轻松使用Git。搜索“ git svn”表明这种做法很普遍，我们也鼓励您尝试一下。
在Svn存储库上使用Git给我带来了好处：
backup/public svn存储库供他人签出这里的所有答案都是以程序员为中心的，如预期的那样，但是，如果您的公司在源代码之外使用修订控制，将会发生什么？有很多不是源代码的文档都可以从版本控制中受益，它们应该靠近代码而不是另一个CMS。大多数程序员并不是孤立地工作-我们作为团队的一员为公司工作。
考虑到这一点，请比较Subversion和git在客户端工具和培训中的易用性。我看不到任何情况分布式修订版本控制系统都将更易于使用或向非程序员解释的情况。我希望证明自己是错误的，因为这样我就可以评估git，并且实际上希望它可以被那些需要版本控制且不是程序员的人所接受。
即使这样，如果管理层问到为什么我们应该从集中式修订控制系统转移到分布式修订控制系统，我也很难给出一个诚实的答案，因为我们不需要它。
免责声明：我很早就对Subversion感兴趣（大约v0.29），因此我很偏颇，但是自那时以来我工作的公司都从我的热情中受益，因为我一直鼓励并支持使用它。我怀疑大多数软件公司都是这样的。如此众多的程序员加入git潮流，我想知道有多少公司会错过在源代码之外使用版本控制的好处吗？即使您为不同的团队使用单独的系统，您也会错过一些好处，例如（统一的）问题跟踪集成，同时增加了维护，硬件和培训要求。
Subversion仍然是一个使用更为广泛的版本控制系统，这意味着它具有更好的工具支持。您会发现几乎所有IDE都具有成熟的SVN插件，并且有不错的资源管理器扩展（例如TurtoiseSVN）。除此之外，我必须同意Michael的观点：Git并不比Subversion更好或更差，而是不同。
David Richards WANdisco关于Subversion / GIT的博客
GIT的出现带来了许多DVCS原教旨主义者，即“吉特隆人”，他们认为除GIT之外的任何事物都是垃圾。Gitterons似乎认为软件工程发生在自己的孤岛上，并且常常忘记大多数组织并没有专门雇用高级软件工程师。没关系，但这不是市场上其他人的想法，我很高兴证明这一点：GIT在最近的市场中所占份额不到3％，而Subversion的用户数量在500万左右，其中一半左右整体市场。
我们看到的问题是Gitterons在Subversion射击（便宜）。诸如“颠覆是如此[缓慢/ cr脚/限制性/不好闻/以一种有趣的方式看着我]这样的推文，现在我有了GIT，[我一生中的所有工作/我的妻子怀孕了/我之后有了女朋友30年的尝试/我在二十一点桌上赢得了六次胜利]。您得到图片。
一切都与执行某件事所需的易用性/步骤有关。
如果我要在PC /笔记本电脑上开发单个项目，则git会更好，因为它更容易设置和使用。您不需要服务器，也不需要在合并时继续输入存储库URL。
如果只有2个人，我想说git也更容易，因为您可以互相推拉。
但是，一旦超出了范围，我就会进行颠覆，因为此时您需要设置一个“专用”服务器或位置。
您可以使用git和SVN一样好地执行此操作，但是由于需要执行其他步骤来与中央服务器同步，因此git的好处远远超过了git。在SVN中，您只需提交即可。在git中，您必须先进行git commit，然后进行git push。仅仅因为您最终做了太多事情，其他步骤就变得烦人了。
SVN还具有更好的GUI工具的优势，但是git生态系统似乎正在迅速赶上，因此从长远来看，我不必担心。
通常，Git和DVCS对于开发人员彼此独立执行大量编码非常有用，因为每个人都有自己的分支。但是，如果您需要其他人进行更改，则她必须提交其本地存储库，然后她必须将该更改集推送给您，或者您必须将其从她那里撤出。
我自己的推理也使我认为，如果您进行集中发行等工作，DVCS会使质量检查和发行管理更加困难。必须负责从其他所有人的存储库中进行该推/拉操作，解决在最初的提交时间之前已经解决的所有冲突，然后进行构建，然后让所有其他开发人员重新同步其存储库。
当然，所有这些都可以通过人工流程解决。DVCS只是打破了集中版本控制所修复的问题，以便提供一些新的便利。
这些都暗示了一些答案，但我想明确指出两点：
1）进行选择性提交的能力（例如， git add --patch）。如果您的工作目录包含不属于同一逻辑更改的多个更改，则Git使得进行仅包含部分更改的提交非常容易。使用Subversion很难。
2）在不公开更改的情况下进行提交的能力。在Subversion中，任何提交都会立即公开，因此不可撤销。这极大地限制了开发人员“提早提交，经常提交”的能力。
Git不只是一个VCS；它也是开发补丁的工具。Subversion仅仅是一个VCS。
我认为Subversion很好..直到您开始合并..或做任何复杂的事情..或做Subversion认为很复杂的事情（例如执行查询以找出哪个分支与特定文件混淆，更改实际来自何处，检测复制和粘贴）等）。
我不同意最终的答案，他说GIT 的主要好处是脱机工作-这固然有用，但是对于我的用例来说，它更像是一个额外的东西。SVK也可以脱机工作，但毫无疑问，我可以选择哪个时间来投入我的学习时间。
只是它功能强大且快速，并且在习惯了这些概念之后就非常有用（在这种意义上是：用户友好）。
有关合并故事的更多详细信息，请参见： 使用git-svn（或类似的）*只是*来帮助进行svn合并？
我绝对喜欢能够在Git中管理我的源代码的本地分支，而又不会浪费中央存储库的资源。在许多情况下，我都会从Subversion服务器中签出代码并运行本地Git存储库以实现此目的。初始化Git存储库不会污染到处都是一堆烦人的.svn文件夹，这也很棒。
就Windows工具的支持而言，TortoiseGit可以很好地处理基础知识，但是除非我想查看日志，否则我还是更喜欢命令行。我非常喜欢Tortoise {Git | SVN}在读取提交日志时的帮助方式。
这是一个错误的问题。专注于git的疣，就至少在某些使用情况下，Subversion为何表面上看起来更好更好，形成论点太容易了。git最初被设计为低级版本控制构造集，并且具有面向Linux开发人员的巴洛克式界面，这一事实使圣战更容易获得吸引力和合法性。Git的拥护者以数百万个工作流程的优势振奋人心，SVN的人宣称这是不必要的。很快，整个辩论被归结为集中式与分布式，这符合企业svn工具社区的利益。这些公司通常发布有关颠覆在企业中的优势的最具说服力的文章，
但这是问题所在：Subversion是体系结构的死胡同。
尽管svn的使用时间是svn的两倍以上，但是您甚至可以轻松地使用git并构建集中式的subversion替代品，即使svn都无法像git一样在任何地方实现基本的合并跟踪。这样做的一个基本原因是使分支与目录相同的设计决策。我不知道为什么他们本来会这样，这肯定会使部分结帐非常简单。不幸的是，这也使得无法正确跟踪历史记录。现在显然您应该使用颠覆存储库布局约定来将分支与常规目录分开，并且svn使用一些启发式方法使事情在日常使用情况下正常工作。但是，所有这些都只是在记录一个非常糟糕且有限的低级设计决策。能够执行版本库差异（而不是目录差异）是版本控制系统的基本和关键功能，它极大地简化了内部结构，从而有可能在其之上构建更智能，更有用的功能。您可以看到扩展颠覆所付出的努力，但与诸如合并解析之类的基本操作相比，它与当前的现代VCS相比却相去甚远。
现在，对于那些仍然相信Subversion在可预见的将来足够好的人，这是我的衷心和不可知论的建议：
Subversion永远不会赶上从RCS和CVS的错误中吸取教训的新型VCS。除非他们从头开始重新构建存储库模型，否则这在技术上是不可能的，但是那真的不是svn吗？无论您认为自己没有现代VCS的功能有多少，您的无知都不会使您免受Subversion的陷阱的困扰，其中许多情况是其他系统无法或无法轻松解决的。
像svn一样，解决方案的技术劣势如此明显是极为罕见的，当然我永远不会对win-vs-linux或emacs-vs-vi提出这样的看法，但是在这种情况下，它是如此明确，源代码控制是开发人员手中的如此基本工具，我认为必须明确指出。不管出于组织原因而使用svn的要求，我恳求所有svn用户不要让他们的逻辑思维错误地认为，更现代的VCS仅对大型开源项目有用。无论开发工作的性质如何，如果您是一名程序员，那么如果您学会了如何使用设计更好的VCS（无论是Git，Mercurial，Darcs还是其他许多类型的VCS），都将成为一名更有效的程序员。
Subversion非常易于使用。在过去的几年中，我从未发现任何问题或无法正常工作。另外，还有许多出色的GUI工具，并且对SVN集成的支持很大。
使用Git，您可以获得更灵活的VCS。您可以像在远程仓库中使用SVN一样使用它，并在其中提交所有更改。但是您也可以在离线状态下使用它，并且仅将更改不时推送到远程存储库。但是Git更复杂，学习曲线更陡峭。我第一次发现自己犯了错误的分支，间接创建分支或收到错误消息，但其中包含有关错误的信息以及我必须在Google进行搜索以获取更好信息的信息不多。一些简单的事情（例如标记的替换（$ Id $））不起作用，但是GIT具有非常灵活的筛选和挂钩机制来合并自己的脚本，因此您可以获得所需的所有东西，但还需要更多的时间和文档阅读时间;）
如果您大多数情况下都是使用本地存储库进行脱机工作，则如果本地计算机上丢失了某些内容，则将没有备份。使用SVN时，您主要是在使用远程存储库，这也是您在另一台服务器上进行备份的时间。Git可以以相同的方式工作，但这并不是Linus拥有SVN2之类的主要目标。它是为Linux内核开发人员和分布式版本控制系统的需求而设计的。
Git比SVN好吗？只需一些版本历史记录和备份机制的开发人员，使用SVN可以轻松自如。经常与分支机构合作，同时测试更多版本或大部分离线工作的开发人员可以从Git的功能中受益。有一些非常有用的功能，例如SVN找不到的隐藏功能，可以使生活更轻松。但另一方面，并非所有人都需要所有功能。因此，我看不到SVN的死机。
Git需要一些更好的文档，并且错误报告必须更有帮助。而且，现有的有用GUI很少。这次，我仅找到1个Linux的GUI，它支持大多数Git功能（git-cola）。Eclipse集成正在运行，但尚未正式发布，并且没有正式的更新站点（只有一些带有定期构建的外部更新站点，可以通过主干http://www.jgit.org/updates进行）因此，这是当今使用Git的首选方法是命令行。
SourceGear的Eric Sink撰写了一系列有关分布式和非分布式版本控制系统之间差异的文章。他比较了大多数流行的版本控制系统的优缺点。非常有趣的阅读。
可以在他的博客www.ericsink.com上找到文章：
对于寻求良好Git GUI的人来说，Syntevo SmartGit可能是一个很好的解决方案。我认为，它的专有但非商业用途免费，可在Windows / Mac / Linux上运行，甚至使用某种git-svn桥支持SVN。
http://subversion.wandisco.com/component/content/article/1/40.html
我认为可以肯定地说，在开发人员中，SVNVs。Git的争论已经有一段时间了，每个人都有更好的观点。在我们于2010年及以后举办的有关Subversion的网络研讨会中，甚至提出了这些问题。
我们的开源总监兼Subversion公司总裁Hyrum Wright谈到了Subversion与Git以及其他分布式版本控制系统（DVCS）之间的区别。
他还谈到了Subversion即将发生的变化，例如下一代工作副本（WC-NG），他认为这将导致许多Git用户转换回Subversion。
观看他的视频，并通过评论此博客或在我们的论坛中发布让我们知道您的想法。注册很简单，只需要一点时间！
Windows中的Git现在已得到很好的支持。
查看GitExtensions = http://code.google.com/p/gitextensions/
和手册以获得更好的Windows Git体验。
我最近一直居住在Git土地上，我喜欢将其用于个人项目，但是鉴于工作人员对需求的看法发生了变化，如果没有紧迫的好处，我还无法将工作项目从Subversion切换到它。此外，我们内部运行的最大项目非常依赖svn：externals，从我到目前为止所看到的来看，它在Git中无法很好地，无缝地工作。
为什么我认为Subversion比Git更好（至少对于我从事的项目而言），主要是因为它的可用性和更简单的工作流程：
http://www.databasesandlife.com/why-subversion-is-better-than-git/