我已经使用Subversion几年了，在使用SourceSafe之后，我只是喜欢Subversion。与TortoiseSVN结合使用，我真的无法想象它会变得更好。

但是，越来越多的开发人员声称Subversion存在问题，我们应该转向新的分布式版本控制系统，例如Git。

Git在Subversion上有何改进？

解决方案：

Google Tech Talk：git上的Linus Torvalds

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

Git Wiki的比较页面

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

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增加了复杂性。创建存储库的两种模式，即检出与克隆，提交与推送......我们必须知道哪些命令在本地工作以及哪些命令与"服务器"一起工作(我假设大多数人仍然喜欢中央的"主存储库" )。

而且，该工具仍然不足，至少在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上是如此)非常出色。

好吧，它是分布式的。基准测试表明它的速度要快得多(考虑到它的分布式特性，差异和日志之类的操作都是本地的，因此在这种情况下当然要快得多)，并且工作文件夹更小(这仍然让我感到震惊)。

当我们使用Subversion或者任何其他客户端/服务器版本控制系统时，实际上是通过签出修订版本在计算机上创建工作副本。这代表了存储库外观的快照。我们可以通过更新来更新工作副本，也可以通过提交来更新存储库。

使用分布式版本控制，我们没有快照，而是整个代码库。想要与3个月大的版本进行比较吗？没问题，计算机上仍旧有3个月的旧版本。这不仅意味着事情要快得多，而且如果我们与中央服务器断开连接，我们仍然可以执行许多惯用的操作。换句话说，我们不仅拥有给定修订版的快照，而且还拥有整个代码库。

我们可能认为Git会在硬盘驱动器上占用大量空间，但是从我所看到的一些基准测试来看，它实际上所占的空间更少。不要问我如何。我的意思是，它是由Linus构建的，我对文件系统了解一两点。

一般来说，Git和DVCS非常适合开发人员彼此独立进行大量编码的开发人员，因为每个人都有自己的分支。但是，如果我们需要其他人进行更改，则她必须提交其本地存储库，然后她必须将该更改集推送给我们，或者我们必须从她那里撤消它。

我自己的推理也使我认为，如果我们进行集中式发行之类的事情，DVCS会使质量检查和发行管理更加困难。必须负责从其他所有人的存储库中进行该推/拉操作，解决在最初的提交时间之前已经解决的所有冲突，然后进行构建，然后让所有其他开发人员重新同步其存储库。

当然，所有这些都可以通过人工流程解决。 DVCS只是打破了集中版本控制所修复的问题，以提供一些新的便利。

这全都涉及做某事所需的易用性/步骤。

如果我要在PC /笔记本电脑上开发单个项目，则git会更好，因为它更容易设置和使用。
我们不需要服务器，也不需要在合并时继续输入存储库URL。

如果只有2个人，我想说git也更容易，因为我们可以互相推拉。

但是，一旦我们超出了这个范围，我就会进行颠覆，因为那时候我们需要设置一个"专用"服务器或者位置。

我们可以使用git和SVN一样好地执行此操作，但是由于需要执行其他步骤来与中央服务器同步，因此git的好处远远超过了git。在SVN中，我们只需提交即可。在git中，我们必须先进行git commit，然后进行git push。仅仅因为我们最终做了太多事情，其他步骤就变得很烦人。

SVN还具有更好的GUI工具的优势，但是git生态系统似乎正在迅速赶上，因此从长远来看，我不必担心。

使用Git，我们几乎可以脱机执行任何操作，因为每个人都有自己的存储库。

制作分支和在分支之间合并确实很容易。

即使我们没有项目的提交权限，我们仍然可以在线拥有自己的存储库，并为补丁发布"推送请求"。每个喜欢补丁程序的人都可以将其加入他们的项目中，包括官方维护人员。

派生一个项目，对其进行修改，并且仍然继续合并来自HEAD分支的错误修正，这是微不足道的。

Git为Linux内核开发人员服务。这意味着它确实非常快(必须如此)，并且可以扩展到成千上万的贡献者。 Git还使用更少的空间(Mozilla存储库的空间最多减少30倍)。

Git非常灵活，非常TIMTOWTDI(有多种方法可以做到)。我们可以使用所需的任何工作流程，Git将支持它。

最后，还有GitHub，这是一个托管Git存储库的好网站。

Git的缺点：

• 这很难学习，因为Git有更多的概念和更多的命令。
• 修订版没有像Subversion中那样的版本号
• 许多Git命令是模糊的，错误消息对用户非常不友好
• 它缺少良好的GUI(例如出色的TortoiseSVN)

Git还使分支和合并变得非常容易。 Subversion 1.5刚刚添加了合并跟踪，但是Git仍然更好。使用Git分支非常快速且便宜。这使得为​​每个新功能创建分支更加可行。与Subversion相比，Oh和Git存储库在存储空间方面非常有效。

Easy Git上有一个漂亮的页面，比较了Git和SVN的实际使用情况，这将使我们了解Git与SVN相比可以做(或者更容易做)的事情。 (从技术上讲，这是基于Easy Git的，它是Git之上的轻量级包装。)

让SubVersion感到困扰的一件事是，它在项目的每个目录中都放置了自己的文件夹，而git仅在根目录中放置了一个文件夹。没什么大不了的，但是类似的小事加起来。

当然，SubVersion具有Tortoise，(通常)非常好。

由于它不需要与中央服务器持续通信的事实，几乎每个命令都可以在不到一秒钟的时间内运行(显然git push / pull / fetch速度较慢，仅因为它们必须初始化SSH连接)。分支要容易得多(一个简单的命令即可分支，一个简单的命令即可合并)

我喜欢DVCS的要点是：

• 我们可以犯坏的事情。没关系，因为在我们发布之前，其他人不会看到它们。发布时间与提交时间不同。
• 因此，我们可以更频繁地进行提交。
• 我们可以合并完整的功能。此功能将有其自己的分支。该分支的所有提交都将与此功能相关。我们可以使用CVCS来实现，但是默认使用DVCS来实现。
• 我们可以搜索历史记录(在功能更改时查找)
• 如果有人搞砸了主存储库，则可以撤消拉动，而无需修复错误。只需清除合并即可。
• 当我们在任何目录中需要源代码管理时，请执行：git init。我们可以提交，撤消更改等。
• 快速(即使在Windows上)

进行相对大型项目的主要原因是第3点改善了沟通能力。其他都是不错的奖励。

Subversion仍然是一个使用更为广泛的版本控制系统，这意味着它具有更好的工具支持。我们会发现几乎所有IDE都具有成熟的SVN插件，并且有不错的资源管理器扩展(例如TurtoiseSVN)。除此之外，我必须同意Michael：Git并不比Subversion更好或者更差，而是不同。

其他答案也很好地解释了Git的核心功能(很棒)。但是，还有很多小方法可以使Git表现得更好，并帮助保持我的生活更加理智。以下是一些小事情：

• Git有一个"干净"的命令。考虑到SVN多长时间将额外的文件转储到磁盘上，SVN迫切需要此命令。
• Git具有" bisect"命令。这真好。
• SVN在每个文件夹中创建.svn目录(Git仅创建一个.git目录)。我们编写的每个脚本以及所做的每个grep都需要编写，以忽略这些.svn目录。我们还需要一个完整的命令(" svn export")，以获取文件的完整副本。
• 在SVN中，每个文件和文件夹都可以来自不同的修订版或者分支。首先，拥有这种自由听起来不错。但这实际上意味着，有100万种不同的方式可以完全搞定本地结帐。 (例如，如果" svn switch"在中途失败，或者我们输入的命令错误)。最糟糕的是：如果遇到某些文件来自一个地方，而另一些文件来自另一个地方的情况，则" svn状态"将告诉我们一切正常。我们需要在每个文件/目录上执行" svn信息"，以发现异常情况。如果" git status"告诉我们事情正常，那么我们可以相信事情确实正常。
• 每当我们移动或者删除某些内容时，我们都必须告诉SVN。 Git会弄清楚的。
• 在Git中，忽略语义更容易。如果忽略模式(例如* .pyc)，则所有子目录都将忽略该模式。 (但是，如果我们真的只想忽略一个目录中的某些内容，则可以)。使用SVN，似乎没有简单的方法可以忽略所有子目录中的模式。
• 另一个涉及忽略文件的项目。 Git使得"私有"忽略设置成为可能(使用文件.git / info / exclude)，该设置不会影响其他任何人。

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

请阅读在Google Code项目上使用Git进行开发

Although Google Code natively speaks
  Subversion, you can easily use Git
  during development. Searching for "git
  svn" suggests this practice is
  widespread, and we too encourage you
  to experiment with it.

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

• 我可以在多台计算机上进行分布式工作，并在它们之间进行提交和拉取
• 我有一个中央的backup / publicsvn存储库，供其他人签出
• 他们可以自由使用Git

我喜欢Git，因为它实际上可以帮助中型到大型团队中的通信开发人员与开发人员进行交流。作为一个分布式版本控制系统，通过其推/拉系统，它可以帮助开发人员创建源代码生态系统，该生态系统有助于管理在单个项目上工作的大量开发人员。

例如，说我们信任5个开发人员，并且仅从其存储库中提取代码。每个开发人员都有他们自己的信任网络，从那里可以提取代码。因此，开发基于开发人员的信任结构，其中代码责任在开发社区之间共享。

当然，这里的其他答案中也提到了其他好处。

"为什么Git比X更好"概述了Git与其他SCM的优缺点。

简要地：

• Git跟踪内容而不是文件
• 分支是轻量级的，合并很容易，我的意思是说真的很容易。
• 它是分布式的，基本上每个存储库都是一个分支。我认为，与Subversion相比，并行和协同开发要容易得多。它还使离线开发成为可能。
• 正如上面链接的网站所示，它不强加任何工作流程，Git可以实现许多工作流程。一个Subversion风格的工作流很容易被模仿。
• Git存储库的文件大小比Subversion存储库小得多。与数十个" .svn"存储库相比，只有一个" .git"目录(请注意，Subversion 1.7及更高版本现在使用单个目录，如Git。)
• 暂存区域很棒，它使我们可以看到要提交的更改，提交部分更改以及进行其他各种操作。
• 当我们进行"混乱的"开发时，或者只是想在仍在处理其他事情(在另一个分支上)时修正错误，隐藏是非常宝贵的。
• 我们可以重写历史记录，这对于准备补丁集和修复错误非常有用(在发布提交之前)
• 还有更多。

有一些缺点：

• 目前还没有很多好的GUI。它是新的，并且Subversion已经存在了很长时间，所以这很自然，因为有一些接口正在开发中。一些不错的工具包括TortoiseGit和Mac的GitHub。
• 目前无法对存储库进行部分检出/克隆(我读到它正在开发中)。但是，有子模块支持。 Git 1.7+支持稀疏签出。
• 即使我(大约一年前)没有发现这种情况，可能很难学习。 Git最近改进了其界面，并且非常用户友好。

在最简单的用法中，Subversion和Git几乎相同。之间没有太大区别：

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

和

git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Git真正令人眼前一亮的是分支机构并与其他人一起工作。

这些都暗示了一些答案，但我想明确指出两点：

1)进行选择性提交的能力(例如，git add --patch`)。如果工作目录包含不属于同一逻辑更改的多个更改，则Git可以非常轻松地进行仅包含部分更改的提交。使用Subversion很难。

2)在不公开更改的情况下进行提交的能力。在Subversion中，任何提交都是立即公开的，因此不可撤消。这极大地限制了开发人员"提早提交，经常提交"的能力。

Git不只是一个VCS；它也是开发补丁的工具。 Subversion仅仅是一个VCS。

这里的所有答案都是按预期的，以程序员为中心，但是，如果公司在源代码之外使用修订控制，会发生什么情况？有很多不是源代码的文档可以从版本控制中受益，它们应该靠近代码，而不是放在另一个CMS中。大多数程序员并不是孤立地工作，我们是团队合作的一部分。

考虑到这一点，请比较Subversion和git在客户端工具和培训中的易用性。我看不到任何分布式修订版本控制系统都将更易于使用或者向非程序员解释的情况。我希望证明自己是错误的，因为这样我就可以评估git，并且实际上希望它可以被那些需要版本控制且不是程序员的人所接受。

即使这样，如果管理层问到为什么我们应该从集中式修订控制系统过渡到分布式修订控制系统，我也很难给出一个诚实的答案，因为我们不需要它。

免责声明：我很早就对Subversion感兴趣(大约在v0.29左右)，因此我有偏见，但是自那时以来我工作的公司都从我的热情中受益，因为我一直鼓励并支持使用Subversion。我怀疑大多数软件公司都是这样的。有这么多的程序员加入git潮流，我想知道有多少公司会错过在源代码之外使用版本控制的好处吗？即使我们为不同的团队使用单独的系统，我们也会错过一些好处，例如(统一的)问题跟踪集成，同时增加了维护，硬件和培训要求。

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是版本控制工具的C
• 关于Git缺乏对不变性的尊重以及DVCS的最佳实践
• DVCS和DAG，第1部分
• DVCS和DAG，第2部分
• DVCS和错误跟踪
• 合并历史记录，DAG和Darcs
• 为什么Git这么快？
• Mercurial，Subversion和Wesley片段

首先，并发版本控制似乎是一个容易解决的问题。一点也不。反正...

SVN非常不直观。 Git更糟。 [讽刺的推测]这可能是因为像并发版本控制之类的难题一样，开发人员对制作一个好的UI并没有太大的兴趣。 [/讽刺推测]

SVN支持者认为他们不需要分布式版本控制系统。我也这么认为。但是，既然我们只使用Git，我就是一个信徒。现在，版本控制对我和团队/项目都有效，而不仅仅是为项目工作。当我需要分支时，我分支。有时，这是一个分支，在服务器上具有相应的分支，有时则没有。更不用说我必须继续研究的所有其他优点(部分由于现代版本控制系统的UI荒唐而荒唐的缺乏)。

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

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

和手册，以获得更好的Windows Git体验。

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

我认为在开发人员中使用SVN Vs是相当安全的。 Git的论据已经激怒了一段时间，每个人都对哪个更好有自己的看法。在我们于2010年及以后举办的有关Subversion的网络研讨会中，甚至在问题中也提到了这一点。

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

他还谈到了Subversion即将发生的变化，例如下一代工作副本(WC-NG)，他认为这将导致许多Git用户转换回Subversion。

观看他的视频，并通过评论此博客或者在我们的论坛中发布让我们知道想法。注册很简单，只需要一点时间！

我绝对喜欢能够在Git中管理我的源代码的本地分支，而又不会浪费中央存储库的资源。在许多情况下，我都会从Subversion服务器中签出代码，然后运行本地Git存储库以实现此目的。初始化Git存储库不会污染到处都是一堆烦人的.svn文件夹，这也很棒。

就Windows工具的支持而言，TortoiseGit能很好地处理基础知识，但是除非我想查看日志，否则我还是更喜欢命令行。我非常喜欢Tortoise {Git | SVN}在读取提交日志时的帮助方式。

我最近一直居住在Git土地上，我喜欢将其用于个人项目，但是鉴于工作人员对需求的看法发生了变化，如果没有紧迫的好处，我还无法将工作项目从Subversion切换到它。而且，我们内部运行的最大项目非常依赖svn：externals，从我到目前为止所看到的来看，它在Git中无法很好地，无缝地工作。

我认为Subversion很好..直到我们开始合并..或者做任何复杂的事情..或者做Subversion认为很复杂的事情(例如执行查询以找出哪个分支与特定文件混淆，更改实际来自何处，检测复制和粘贴) ， 等等)...

我不同意最终的答案，他说GIT的主要好处是脱机工作，这当然有用，但是对于我的用例来说，它更像是一个额外的东西。 SVK也可以脱机工作，但毫无疑问，我可以选择哪个时间来投入我的学习时间。

只是，它非常强大，快速，而且在习惯了非常有用的概念之后(是的，从某种意义上说：用户友好)。

有关合并故事的更多详细信息，请参见：
使用git-svn(或者类似的)只是来帮助svn合并？

David Richards WANdisco关于Subversion / GIT的博客

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 blackHyman table]. You get the picture.

为什么我认为Subversion比Git更好(至少对于我从事的项目而言)，主要是因为它的可用性和更简单的工作流程：

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