Question

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

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

Git如何改进Subversion？

Answer 1

Git并不比Subversion好。但也不会更糟。这是不同的。

关键的区别在于它是分散的。想象一下，如果您是一名开发人员，您可以在笔记本电脑上进行开发，并希望拥有源代码控制功能，以便您可以返回3个小时。

使用Subversion，您遇到了一个问题：SVN存储库可能位于您无法访问的位置（在您的公司，此时您还没有互联网），您无法提交。如果你想复制你的代码，你必须完全复制/粘贴它。

使用Git，你没有这个问题。您的本地副本是一个存储库，您可以提交它并获得源代码管理的所有好处。当您重新获得与主存储库的连接时，您可以对其进行提交。

一开始看起来很不错，但请记住这种方法的复杂性。

Git似乎是“新的，闪亮的，酷的”东西。这绝不是坏事（毕竟Linus为Linux内核开发编写了它的原因），但我觉得很多人跳过“分布式源代码控制”列车只是因为它是新的并且由Linus Torvalds编写，实际上并没有知道为什么/如果它更好。

Subversion存在问题，但Git，Mercurial，CVS，TFS等也存在问题。

编辑：所以这个答案现在已经有一年了，仍会产生很多赞成票，所以我想我会补充一些解释。在写这篇文章的最后一年，Git获得了很多动力和支持，特别是因为像GitHub这样的网站真的起飞了。我现在正在使用Git和Subversion，我想分享一些个人见解。

首先，Git在分散工作时起初可能会让人感到困惑。什么是遥控器？以及如何正确设置初始存储库？一开始就出现了两个问题，特别是与SVN的简单“svnadmin创建”相比，Git的“git init”可以采用参数--bare和--shared这似乎是设置集中的“正确”方式库。这是有原因的，但它增加了复杂性。 “checkout”命令的文档对于转换的人来说非常混乱 - “正确”的方式似乎是“git clone”，而“git checkout”似乎可以切换分支。

当你分散时，Git真的很棒。我家里有一台服务器，路上有一台笔记本电脑，SVN在这里效果不好。使用SVN，如果我没有连接到存储库，我就无法拥有本地源代码控制（是的，我知道SVK或者有关复制repo的方法）。使用Git，无论如何这都是默认模式。这是一个额外的命令（git commit在本地提交，而git push origin master将master分支推送到名为“origin”的远程）。

如上所述：Git增加了复杂性。创建存储库，checkout与clone，commit与push的两种模式......你必须知道哪些命令在本地工作，哪些命令与“服务器”一起工作（我假设大多数人仍然喜欢中央“主存储库” ）。

此外，至少在Windows上，工具仍然不足。是的，有一个Visual Studio AddIn，但我仍然使用git bash和msysgit。

SVN的优势在于它更容易学习：如果您知道如何创建，提交和结帐，那么您的存储库，所有更改都是如此，您已经准备好了，可以选择分支，更新等内容等等。

如果某些开发人员并不总是连接到主存储库，那么Git的优势在于它更适合。而且，它比SVN快得多。从我听到的情况来看，分支和合并支持要好得多（这是预期的，因为这些是编写它的核心原因）。

这也解释了为什么它在互联网上获得如此多的关注，因为Git非常适合开源项目：Just Fork it，将您的更改提交给您自己的Fork，然后让原始项目维护者提取您的更改。有了Git，这才有效。真的，在Github上试一试，这很神奇。

我还看到Git-SVN Bridges：中央存储库是一个Subversion存储库，但开发人员在本地使用Git，然后桥接器将其更改推送到SVN。

但即使有这么长时间的补充，我仍然坚持我的核心信息：Git不是更好或更糟，它只是不同。如果您需要“离线源控制”并且愿意花一些额外的时间来学习它，那就太棒了。但是如果你有一个严格集中的源代码控制和/或正在努力引入源代码控制，因为你的同事不感兴趣，那么SVN的简单性和优秀的工具（至少在Windows上）就会闪耀。

Answer 2

使用Git，你几乎可以做任何离线操作，因为每个人都有自己的存储库。

在分支之间建立分支和合并非常容易。

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

分叉项目，修改它，并且仍然保持合并来自HEAD分支的错误修正是微不足道的。

Git适用于Linux内核开发人员。这意味着它真的很快（必须），并扩展到成千上万的贡献者。 Git也使用更少的空间（Mozilla存储库的空间减少了30倍）。

Git非常灵活，非常TIMTOWTDI（有多种方法可以做到这一点）。你可以使用你想要的任何工作流程，Git会支持它。

最后，有GitHub，一个用于托管Git存储库的绝佳网站。

Git的缺点：

学习起来要困难得多，因为Git有更多的概念和更多的命令。
修订版没有像subversion一样的版本号
许多Git命令含糊不清，错误消息非常不友好
它缺少一个好的GUI（例如伟大的TortoiseSVN）

Answer 3

其他答案在解释Git的核心功能方面做得很好（很棒）。但也有很多小方式，Git表现得更好，有助于让我的生活更加清醒。以下是一些小事：

Git有'干净'命令。 SVN迫切需要这个命令，考虑它会在磁盘上转储额外文件的频率。
Git有'bisect'命令。这很好。
SVN在每个文件夹中创建.svn目录（Git只创建一个 .git目录）。您编写的每个脚本以及您执行的每个grep都需要编写以忽略这些.svn目录。您还需要一个完整的命令（“svn export”）才能获得一份合理的文件副本。
在SVN中，每个文件＆amp;文件夹可以来自不同的修订版或分支。起初，拥有这种自由听起来不错。但这实际上意味着有一百万种不同的方式让您的本地结账完全搞砸了。（例如，如果“svn switch”中途失败，或者输入的命令错误）。最糟糕的是：如果你遇到某些文件来自一个地方，而其中一些来自另一个地方的情况，“svn状态”会告诉你一切正常。您需要在每个文件/目录上执行“svn info”以发现奇怪的事情。如果“git status”告诉你事情是正常的，那么你可以相信事情是正常的。
无论何时移动或删除某些内容，都必须告诉SVN。 Git会弄明白的。
在Git中忽略语义更容易。如果忽略模式（例如* .pyc），所有子目录将忽略它。（但如果你真的想忽略一个目录的东西，你可以）。使用SVN，似乎没有简单的方法可以忽略所有子目录中的模式。
涉及忽略文件的另一项。 Git可以使用“私有”忽略设置（使用文件.git / info / exclude），这不会影响其他任何人。

Answer 4

“Why Git is Better than X”概述了Git与其他SCM的各种利弊。

简言之：

Git跟踪内容而不是文件
分支机构是轻量级的，合并是简单，我的意思是非常简单。
它是分布式的，基本上每个存储库都是一个分支。在我看来，与Subversion相比，并发和协作开发要容易得多。它还可以实现离线开发。
没有强制执行任何工作流程，如the above linked website所示，Git可以实现许多工作流程。 Subversion风格的工作流程很容易被模仿。
Git存储库的文件大小小于Subversion存储库。只有一个“.git”目录，而不是几十个“.svn”存储库（注意Subversion 1.7和更高版本now uses a single directory就像Git一样。）
登台区域非常棒，它允许您查看要提交的更改，提交部分更改以及执行各种其他操作。
存储在您进行“混乱”开发时非常宝贵，或者只是想在您还在处理其他事情时修复错误（在不同的分支上）。
您可以重写历史记录，这对于准备补丁集和修复错误非常有用（在发布提交之前）
...和很多更多。

有一些缺点：

目前还没有很多优秀的GUI。这是新的，Subversion已经存在了很长时间，所以这很自然，因为开发中有一些接口。一些好的包括TortoiseGit和GitHub for Mac。
~~目前无法进行部分检查/克隆存储库（我读到它正处于开发阶段）。但是，有子模块支持。~~ Git 1.7+ supports sparse checkouts。
虽然我没有发现这种情况（约一年前），但可能更难学习。 Git最近改进了界面并且非常友好。

在最简单的用法中，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真正闪耀的是分支和与其他人合作。

Answer 5

Google Tech Talk：Linus Torvalds on git

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

Git Wiki的比较页面

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

Answer 6

嗯，它是分发的。基准测试表明它的速度要快得多（鉴于它的分布式特性，差异和日志等操作都是本地的，所以当然它在这种情况下速度更快），工作文件夹更小（这仍然让我感到震惊）。

当您处理subversion或任何其他客户端/服务器版本控制系统时，您实际上是通过签出修订版在您的计算机上创建工作副本。这表示存储库的外观时间快照。您可以通过更新更新工作副本，并通过提交更新存储库。

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

你认为Git会在你的硬盘上占用一大块空间，但是从我看过的几个基准测试中，它实际上需要更少。别问我怎么样。我的意思是，它是由Linus构建的，他对文件系统了解了一两件事。

Answer 7

我喜欢DVCS的主要观点是：

你可以犯下破碎的东西。这没关系，因为在您发布之前，其他人不会看到它们。发布时间与提交时间不同。
因此，您可以更频繁地提交。
您可以合并完整的功能。这个功能将有自己的分支。此分支的所有提交都与此功能相关。您可以使用CVCS，但DVCS是默认值。
您可以搜索历史记录（查找功能何时更改）
如果有人搞砸了主存储库，你可以撤消拉取，你不需要修复错误。只需清除合并。
当你需要任何目录中的源代码控制时，请执行：git init。并且您可以提交，撤消更改等...
速度很快（即使在Windows上）

一个相对较大的项目的主要原因是第3点改善了沟通。其他是很好的奖金。

Answer 8

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

请阅读Develop with Git on a Google Code Project

虽然谷歌代码原生发言 Subversion，你可以轻松使用Git 在开发期间。正在寻找“git svn“表明这种做法是普遍，我们也鼓励你试验它。

在Svn存储库上使用Git可以带来好处：

我可以在几个上工作分发机器，承诺和拉动和他们
我有一个中央 backup/public svn存储库供其他人查看
他们可以自由地使用Git

Answer 9

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

考虑到这一点，比较Subversion和git之间在客户端工具和培训中的易用性。我看不到任何分布式版本控制系统将更容易使用或向非程序员解释的场景。我很乐意被证明是错的，因为那样我就能够评估git，并且实际上希望它能够被那些需要版本控制并且不是程序员的人所接受。

即便如此，如果管理层要求我们为什么要从集中式转发到分布式版本控制系统，我很难给出一个诚实的答案，因为我们不需要它。

免责声明：我很早就对Subversion产生了兴趣（大约在第29节），所以很明显我有偏见，但是那段时间以来我工作的公司都受益于我的热情，因为我鼓励并支持它的使用。我怀疑这是大多数软件公司的情况。有这么多程序员跳上git的潮流，我想知道有多少公司会错过在源代码之外使用版本控制的好处？即使你有不同团队的独立系统，你也会错过一些好处，例如（统一）问题跟踪集成，同时增加维护，硬件和培训要求。

Answer 10

Subversion仍然是一个更常用的版本控制系统，这意味着它有更好的工具支持。你会发现几乎所有IDE的成熟SVN插件，并且有很好的资源管理器扩展（如TurtoiseSVN）。除此之外，我将不得不同意Michael：Git并不比Subversion更好或更差，它是不同的。

Answer 11

SubVersion令我烦恼的一件事是它将自己的文件夹放在项目的每个目录中，而git只将一个放在根目录中。并非这么大的交易，但是这样的事情很少。

当然，SubVersion有Tortoise，[通常]非常好。

Answer 12

David Richards WANdisco Blog on Subversion / GIT

GIT的出现带来了一系列DVCS原教旨主义者 - “Gitterons” - 认为GIT以外的任何东西都是垃圾。 Gitterons似乎认为软件工程在他们自己的岛上发生，并且经常忘记大多数组织不专门聘请高级软件工程师。这没关系，但不是其他市场的想法，我很乐意证明这一点：GIT，最后看起来不到3％的市场，而Subversion在500万用户和大约一半的用户整体市场。

我们看到的问题是Gitterons在Subversion上射击（便宜）。像Subversion这样的推文是如此[缓慢/蹩脚/限制/闻不到好/以有趣的方式看着我]现在我有GIT和[一切都在我的生活中工作/我的妻子怀孕/我有一个女朋友后30年的尝试/我赢得六次在二十一点桌上运行]。你得到了照片。

Answer 13

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

Answer 14

这一切都与易用性/做某事所需的步骤有关。

如果我在我的PC /笔记本电脑上开发一个项目，git会更好，因为设置和使用起来要容易得多。您不需要服务器，并且在进行合并时无需继续键入存储库URL。

如果只有2个人，我会说git也比较容易，因为你可以互相推拉。

一旦你超越了这个，我会去颠覆，因为那时你需要设置一个'专用'服务器或位置。

使用git和SVN一样，你也可以这样做，但是需要做一些与中央服务器同步的额外步骤，因此git的好处超过了。在SVN中你只需要提交。在git中你必须git commit，然后git push。额外的步骤很烦人，因为你最终做了这么多。

SVN还有更好的GUI工具的好处，但是git生态系统似乎很快就会迎头赶上，所以从长远来看我不会担心这个。

Answer 15

Easy Git有一个很好的页面，比较了Git and SVN的实际用法，它可以让你了解Git与SVN相比可以做什么（或者更容易做些什么）。（从技术上讲，这是基于Easy Git，它是Git上的轻量级包装器。）

Answer 16

Git和DVCS一般非常适合开发人员彼此独立编码，因为每个人都有自己的分支。但是，如果你需要从别人那里做出改变，她必须承诺给她当地的回购，然后她必须将这个变更集推送给你，否则你必须从她那里取出。

我自己的推理也让我觉得如果你做集中发布之类的事情，DVCS会让QA和发布管理变得更难。有人必须负责从其他人的存储库执行推/拉，解决在之前的初始提交时已经解决的任何冲突，然后进行构建，然后让所有其他开发人员重新同步他们的存储库。

当然，所有这一切都可以用人类过程来解决; DVCS刚刚打破了通过集中版本控制修复的东西，以便提供一些新的便利。

Answer 17

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

例如，假设您信任5位开发人员，并且只从其存储库中提取代码。每个开发人员都有自己的信任网络，从中提取代码。因此，开发基于开发人员的信任结构，其中代码责任在开发社区之间共享。

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

Answer 18

这些答案已经提到了一些，但我想明确指出两点：

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

2）在不将更改公开的情况下提交的能力。在Subversion中，任何提交都是立即公开的，因此是不可撤销的。这极大地限制了开发人员“提前提交，经常提交”的能力。

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

Answer 19

我认为Subversion很好..直到你开始合并..或做任何复杂的事情......或做任何事情Subversion认为是复杂的（比如做查询以找出哪些分支与特定文件混淆，哪里有变化实际来自，检测复制和粘贴等）...

我不同意获胜的答案，说GIT的主要好处是离线工作 - 它肯定是有用的，但它更像是我的用例的额外内容。 SVK也可以脱机工作，对我来说仍然没有问题可以投入我的学习时间。

它只是它非常强大和快速，并且在习惯了概念之后 - 非常有用（是的，从这个意义上说：用户友好）。

有关合并故事的更多详细信息，请参阅： Using git-svn (or similar) *just* to help out with an svn merge?

Answer 20

我非常希望能够在Git中管理我的源代码的本地分支，而不会混淆中央存储库的水。在许多情况下，我将从Subversion服务器检出代码并运行本地Git存储库，以便能够执行此操作。初始化Git存储库并不会污染文件系统，并且到处都是一堆烦人的.svn文件夹。

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

Answer 21

由于它不需要经常与中央服务器通信，因此几乎每个命令都在不到一秒的时间内运行（显然git push / pull / fetch因为必须启动SSH连接而变慢）。分支更容易（一个简单的分支命令，一个简单的命令合并）

Answer 22

这是一个错误的问题。很容易专注于git的瑕疵并制定一个关于为什么颠覆表面上更好的论据，至少对于一些用例来说。事实上，git最初被设计为低级版本控制构造集，并且具有巴洛克式的linux开发人员界面，使得神圣战争更容易获得牵引力和合法性。 Git的支持者为鼓提供了数以百计的工作流程优势，而这些优势让人觉得不必要。很快，整个辩论被构建为集中式和分布式，这符合企业svn工具社区的利益。这些公司通常发表有关颠覆在企业中的优势的最有说服力的文章，取决于git的不安全感以及svn企业为其产品的长期成功做好准备。

但问题在于： Subversion是一个架构死胡同。

虽然你可以很容易地使用git并构建一个集中的subversion替换，尽管svn已经存在了两倍以上，但是从来没有能够获得基本的合并跟踪工作，就像在git中一样。一个基本原因是设计决策使分支与目录相同。我不知道他们为什么这么做，这肯定会使部分结账非常简单。不幸的是，这也使得无法正确追踪历史。现在显然你应该使用subversion存储库布局约定来将分支与常规目录分开，并且svn使用一些启发式方法使事情适用于日常用例。但所有这些只是针对一个非常糟糕和有限的低级别设计决策。能够执行存储库方面的差异（而不是目录方式差异）是版本控制系统的基本和关键功能，并且极大地简化了内部，使得在其上构建更智能和有用的功能成为可能。您可以看到延伸颠覆所付出的努力程度，但在合并解析等基本操作方面，目前的现代VCS数量还有多远。

现在，对于那些仍然相信Subversion在可预见的未来足够好的人来说，这是我的心扉和不可知的建议：

颠覆将永远赶不上从RCS和CVS的错误中吸取教训的新版VCS;除非他们从头开始重新整理存储库模型，否则技术上是不可能的，但那么它真的不是真的吗？无论你认为自己没有多少现代VCS的能力，你的无知都无法保护你免受Subversion的陷阱，其中许多是在其他系统中不可能或很容易解决的情况。

极为罕见的是，解决方案的技术劣势与svn一样明显，我当然不会对win-vs-linux或emacs-vs-vi发表这样的意见，但在这种情况下它是如此清晰，源代码控制是开发人员库中的一个基本工具，我觉得必须明确说明。无论出于组织原因要求使用svn，我都恳请所有svn用户不要让他们的逻辑思维构造错误的信念，即更现代的VCS只对大型开源项目有用。无论您的开发工作的性质如何，如果您是程序员，如果您学习如何使用设计更好的VCS，无论是Git，Mercurial，Darcs还是其他许多人，您将成为更有效的程序员。

Answer 23

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的最佳方式是命令行。

Answer 24

来自SourceGear的

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

Answer 25

对于寻找优秀Git GUI的人来说，Syntevo SmartGit可能是一个很好的解决方案。它的专有但免费用于非商业用途，可以在Windows / Mac / Linux上运行，甚至可以使用某种git-svn桥支持SVN。

Answer 26

首先，并发版本控制似乎是一个容易解决的问题。它根本不是。总之...

SVN非常不直观。 Git更糟糕。 [sarcastic-speculation]这可能是因为开发人员喜欢并发版本控制等硬问题，对制作良好的UI没有太大兴趣。 [/讽刺投机]

SVN支持者认为他们不需要分布式版本控制系统。 我也是这么想的。但是现在我们只使用Git，我是一个信徒。现在版本控制适用于我和团队/项目，而不仅仅是为项目工作。当我需要一个分支时，我分支。有时它是一个在服务器上有相应分支的分支，有时它不会。更不用说我将要研究的所有其他优点（部分归功于现代版本控制系统的神秘和荒谬的UI缺乏）。