为什么Git比Subversion好?

谷歌技术讲座:Linus Torvalds谈git

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

Git Wiki的比较页面

< a href = " http://git.or。cz / gitwiki GitSvnComparsion nofollow noreferrer“rel = > http://git.or.cz/gitwiki/GitSvnComparsion < / >

Git并不比Subversion好。但也不是更糟。这是不一样的。

关键的区别在于它是去中心化的。想象一下你是一个在路上的开发人员，你在你的笔记本电脑上开发，你想要有源代码控制，这样你就可以回到3小时前。

使用Subversion时，您会遇到一个问题:SVN存储库可能位于您无法到达的位置(在您的公司中，并且您目前没有互联网)，您无法提交。如果你想复制你的代码，你必须复制/粘贴它。

使用Git，您就不会遇到这个问题。您的本地副本是一个存储库，您可以提交它并获得源代码控制的所有好处。当您重新获得到主存储库的连接时，您可以针对它提交。

一开始看起来不错，但是要记住这种方法增加了复杂性。

Git似乎是“新的、闪亮的、酷的”东西。它绝对不坏(毕竟Linus为Linux内核开发写了它是有原因的)，但是我觉得很多人只是因为它是新的并且是由Linus Torvalds写的，就跳上了“分布式源代码控制”这列火车，而不知道为什么/它是否更好。

Subversion有问题，但是Git、Mercurial、CVS、TFS等等也有问题。

编辑:所以这个答案现在已经有一年了，仍然产生了很多赞，所以我想我会添加一些更多的解释。在写这篇文章后的去年，Git获得了很多动力和支持，特别是在像GitHub这样的网站真正起飞之后。我现在同时使用Git和Subversion，我想分享一些个人见解。

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

当你去中心化的时候，Git真的会发光。我家里有一台服务器，路上有一台笔记本电脑，SVN在这里根本不能很好地工作。使用SVN，如果我没有连接到存储库，我就不能进行本地源代码控制(是的，我知道SVK或复制回购的方法)。对于Git，这是默认模式。这是一个额外的命令(git commit在本地提交，而git push origin master将主分支推到名为“origin”的远程)。

如上所述:Git增加了复杂性。创建存储库的两种模式，签出vs克隆，提交vs推…您必须知道哪些命令在本地工作，哪些命令在“服务器”上工作(我假设大多数人仍然喜欢中央的“主存储库”)。

而且，工具仍然不够，至少在Windows上是这样。是的，有一个Visual Studio插件，但我仍然使用git bash和msysgit。

SVN的优点是学习起来简单得多:有您的存储库，所有针对它的更改，如果您知道如何创建、提交和签出，您就可以准备好，并可以在以后提取分支、更新等内容。

Git的优势在于，如果一些开发人员不总是连接到主存储库，它会更适合。而且，它比SVN快得多。据我所知，分支和合并支持要好得多(这是意料之中的，因为这是编写它的核心原因)。

这也解释了为什么它在互联网上获得了如此多的关注，因为Git非常适合开源项目:只需Fork它，将您的更改提交到您自己的Fork，然后让原始项目维护者提取您的更改。使用Git，这就可以了。真的，在Github上试试吧，太神奇了。

我还看到了Git-SVN网桥:中央存储库是一个Subversion repo，但开发人员在本地使用Git，网桥将他们的更改推到SVN。

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

它是分布的。基准测试表明，它的速度要快得多(考虑到它的分布式性质，像diffs和log这样的操作都是本地的，所以在这种情况下，它当然要快得多)，而且工作文件夹也更小(这仍然让我大吃一惊)。

当你在subversion或任何其他客户端/服务器版本控制系统上工作时，你实际上是通过检验修订在你的机器上创建工作副本。这代表了存储库外观的时间快照。通过更新更新工作副本，通过提交更新存储库。

使用分布式版本控制，您没有快照，而是拥有整个代码库。想要一个3个月大的版本吗?没问题，3个月前的版本还在你的电脑上。这不仅意味着速度更快，而且如果您与中央服务器断开连接，您仍然可以执行许多您习惯的操作。换句话说，您不仅拥有给定修订的快照，而且拥有整个代码库。

您可能认为Git会占用大量硬盘空间，但从我看到的几个基准测试来看，它实际上占用的空间更少。不要问我怎么做。我的意思是，它是由莱纳斯构建的，我猜他对文件系统略知一二。

Git和DVCS通常都非常适合于独立编写大量代码的开发人员，因为每个人都有自己的分支。但是，如果您需要从其他人那里进行更改，她必须提交给她的本地回购，然后她必须将该更改集推给您，或者您必须从她那里获取更改集。

我自己的推理也让我认为，如果你做集中发布之类的事情，DVCS会让QA和发布管理变得更加困难。必须有人负责从其他人的存储库中进行推送/拉取，解决任何在最初提交时就可以解决的冲突，然后进行构建，然后让所有其他开发人员重新同步他们的回购。

当然，所有这些都可以通过人工流程来解决;DVCS只是破坏了一些由集中式版本控制修复的东西，以便提供一些新的便利。

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

如果只有两个人，我会说git也更简单，因为你可以互相推拉。

一旦你超越了这一点，我就会选择颠覆，因为在这一点上你需要设置一个“专用”服务器或位置。

使用git可以像使用SVN一样做到这一点，但是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相比，Git存储库的存储空间非常有效。

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

SubVersion最让我恼火的一点是它把自己的文件夹放在项目的每个目录中，而git只把一个文件夹放在根目录中。这不是什么大问题，但像这样的小事积少成多。

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

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

我喜欢DVCS的主要原因是:

1. 你可以犯错。这无关紧要，因为在你发表之前其他人不会看到它们。发布时间与提交时间不同。
2. 正因为如此，你可以更频繁地做出承诺。
3. 您可以合并完整的功能。这个功能将有自己的分支。这个分支的所有提交都将与这个功能相关。你可以用CVCS来做，但是DVCS是默认的。
4. 您可以搜索历史记录(查找函数何时更改)
5. 如果有人搞砸了主存储库，您可以撤销拉操作，不需要修复错误。清除合并。
6. 当你需要在任何目录下的源代码控制时:git init。你可以提交，撤销更改等等…
7. 速度很快(即使在Windows上)

一个相对较大的项目的主要原因是由点3创建的改进的交流。其他的则是不错的奖金。

Subversion仍然是一种更常用的版本控制系统，这意味着它有更好的工具支持。你会发现几乎任何IDE都有成熟的SVN插件，并且有很好的资源管理器扩展可用(如TurtoiseSVN)。除此之外，我不得不同意迈克尔: Git并不比Subversion更好或更差，它是不同的。

其他的回答很好地解释了Git的核心特性(这些特性非常棒)。但也有很多小方式，Git表现得更好，帮助我的生活更理智。以下是一些小细节:

1. Git有一个“clean”命令。SVN非常需要这个命令，因为它会频繁地在磁盘上转储额外的文件。
2. Git有'bisect'命令。它很好。
3. SVN在每个文件夹中创建。SVN目录(Git只创建一个 . Git目录)。您编写的每个脚本和执行的每个grep都需要编写来忽略这些.svn目录。您还需要一个完整的命令(“svn export”)来获得文件的正常副本。
4. 在SVN中，每个文件&文件夹可以来自不同的版本或分支。起初，拥有这种自由听起来不错。但这实际上意味着，有一百万种不同的方式可以让你的本地结帐完全搞砸。(例如，如果“svn switch”中途失败，或者如果您输入了错误的命令)。最糟糕的是:如果您遇到这样的情况，其中一些文件来自一个地方，而另一些来自另一个地方，“svn状态”将告诉您一切正常。您需要在每个文件/目录上执行“svn info”才能发现事情有多奇怪。如果“git status”告诉您一切正常，那么您可以相信一切确实正常。
5. 无论何时移动或删除某些东西，都必须告诉SVN。Git会自己想出来的。
6. 在Git中忽略语义更容易。如果你忽略了一个模式(如*.pyc)，它将被所有子目录忽略。(但是如果您真的想为一个目录忽略某些内容，您可以这样做)。对于SVN，似乎没有简单的方法可以忽略所有子目录中的模式。
7. 另一项涉及忽略文件。Git允许“私有”忽略设置(使用. Git /info/exclude文件)，这不会影响其他人。

请阅读在谷歌代码项目上使用Git开发

虽然谷歌代码原生说话 Subversion，可以轻松使用Git 在开发过程中。搜索“git” Svn建议这种做法是正确的 广泛传播，我们也鼓励你

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

1. 我可以工作分布式上几个 机器，承诺和从 和他们
2. 我有一个中央 backup/public svn储存库供其他人检查
3. 他们可以自由地使用Git

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

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

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

“为什么Git比X好”概述了Git与其他scm的各种优缺点。

简要:

• Git跟踪内容而不是文件
• 分支是轻量级的和合并是容易，我的意思是很简单。
• 它是分布式的，基本上每个存储库都是一个分支。在我看来，与Subversion相比，并行和协作地开发要容易得多。它也使得离线开发成为可能。
• 它不会强加任何工作流程，正如在以上连结网站中看到的，Git有许多可能的工作流。颠覆风格的工作流很容易被模仿。
• Git仓库比Subversion仓库更文件大小较小。只有一个。”Git“目录，而不是几十个”。svn"存储库(注意Subversion 1.7和更高版本的现在使用单个目录，如Git。)
• 暂存区域非常棒，它允许你看到你将要提交的更改，提交部分更改和做其他各种事情。
• 藏是非常宝贵的，当你做“混乱”的开发，或只是想修复一个错误，而你仍然在做其他事情(在不同的分支)。
• 你可以改写历史，这对于准备补丁集和修复错误非常有用(之前你发布提交)
• …和一个很多更多。

有一些缺点:

• 目前还没有很多好的gui。它是新的，Subversion已经存在了很长时间，所以这是很自然的，因为有一些接口正在开发中。一些好的方法包括TortoiseGit和GitHub for Mac。
• 存储库的部分签出/克隆目前是不可能的(我读到它在开发中)。但是，有子模块支持。 Git 1.7+支持稀疏签出。
• 这可能更难学，尽管我(大约一年前)并没有发现这种情况。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真正的亮点在于分支和与其他人一起工作。

一些回答已经提到了这些问题，但我想明确说明两点:

1)执行选择性提交的能力(例如，git add --patch)。如果您的工作目录包含多个不属于同一逻辑更改的更改，Git可以很容易地提交只包含部分更改的提交。对于Subversion，这是很困难的。

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

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

这里所有的答案都是意料之中的，以程序员为中心，但是如果你的公司在源代码之外使用修订控制会发生什么呢?有很多文档不是源代码，它们受益于版本控制，应该与代码接近，而不是在另一个CMS中。大多数程序员都不是孤立地工作——我们作为团队的一部分为公司工作。

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

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

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

Subversion非常容易使用。在过去的几年里，我从来没有发现任何问题或事情没有像预期的那样工作。此外，还有许多优秀的GUI工具，对SVN集成的支持也很大。

如果您主要使用本地存储库离线工作，那么如果您的本地机器上丢失了某些东西，则没有备份。使用SVN，您主要使用远程存储库，同时您的备份也在另一个服务器上… Git也可以以同样的方式工作，但这并不是Linus的主要目标，要有类似SVN2的东西。它是为Linux内核开发人员和分布式版本控制系统的需要而设计的

Git比SVN好吗?只需要一些版本历史记录和备份机制的开发人员可以轻松地使用SVN。经常使用分支、同时测试更多版本或主要离线工作的开发人员可以从Git的特性中受益。有一些非常有用的特性，比如SVN中没有的存储特性，可以使工作更轻松。但另一方面，并非所有人都需要所有功能。所以我看不到SVN的死角。

• 读取Diffs

• Git是版本控制工具的C

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

• DVCS and DAGs, Part 1 . DAGs, Part 1

• DVCS and DAGs, Part 2 . DAGs, Part 2

• DVCS和Bug跟踪

• 合并历史，dag和Darcs

• 为什么Git这么快?< / >

• Mercurial, Subversion和Wesley Snipes

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

SVN非常不直观。Git更糟糕。这可能是因为开发人员喜欢并发版本控制这样的难题，他们对制作一个好的UI没有多大兴趣。[/ sarcastic-speculation]

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和Git的争论已经激烈了一段时间，每个人都有自己的观点，哪个更好。这甚至在我们2010年及以后关于颠覆的网络研讨会的问题中被提出。

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

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

请观看他的视频，并通过在这个博客上评论或在我们的论坛上发帖来告诉我们你的想法。注册很简单，只需要一点时间!

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

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

我最近一直住在Git的土地上，我喜欢用它来做个人项目，但是我还不能把工作项目从Subversion转换到Git上，因为它改变了工作人员的想法，而且没有紧迫的好处。此外，我们内部运行的最大项目非常依赖svn:外部，从我目前所看到的来看，它在Git中并不是很好和无缝地工作。

我认为Subversion很好。直到你开始合并…或者做任何复杂的事情。或者做任何Subversion认为复杂的事情(比如查询哪些分支弄乱了特定的文件，实际上的变化来自哪里，检测复制粘贴等等)…

我不同意获胜的答案，说GIT的主要好处是离线工作-它当然有用，但它更像是我的用例的额外功能。SVK也可以离线工作，对我来说，把我的学习时间投入到哪一个是没有问题的)。

只是它非常强大、快速，而且——在习惯了这些概念之后——非常有用(是的，在这个意义上:用户友好)。

David Richards WANdisco关于Subversion / GIT的博客

GIT的出现带来了一群DVCS原教旨主义者——“Gitterons”——他们认为除了GIT以外的任何东西都是垃圾。Gitterons似乎认为软件工程只发生在他们自己的地盘上，而且经常忘记大多数组织并不专门雇佣高级软件工程师。这是可以的，但这不是其他市场的想法，我很高兴证明这一点:GIT在最近的一次调查中只有不到3%的市场份额，而Subversion有500万用户，占整个市场的一半左右。

我们所看到的问题是Gitterons正在向Subversion发射(廉价的)射击。像这样的推文“颠覆太[缓慢/蹩脚/限制性/闻起来不好闻/以一种有趣的方式看着我]，现在我有了GIT和[生活中一切都很顺利/我妻子怀孕了/我努力了30年才有了女朋友/我在21点赌桌上赢了6次]。你懂的。

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

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

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

这个问题问得不对。我们很容易关注git的缺点，并阐述为什么subversion表面上更好，至少在某些用例中是这样。git最初被设计为一个低级版本控制构造集，并且拥有一个巴洛克式的面向linux开发人员的界面，这使得圣战更容易获得吸引力和认可的合法性。Git的支持者鼓吹着数百万个工作流的优点，而svn却宣称这些优点是不必要的。很快，整个争论就变成了集中式vs分布式，这符合企业svn工具社区的利益。这些公司通常会发表关于subversion在企业中的优越性的最令人信服的文章，它们依赖于git的可感知的不安全性和svn的企业就绪性来实现其产品的长期成功。

但这里有一个问题:颠覆是架构的死胡同。

虽然你可以很容易地使用git来构建一个集中式的subversion替代品，但尽管svn存在的时间是git的两倍多，但它从来都不能像git一样完成基本的合并跟踪工作。这样做的一个基本原因是使分支与目录相同的设计决策。我不知道他们最初为什么要这样做，这确实让部分结帐变得非常简单。不幸的是，这也使得正确追踪历史成为不可能。显然，现在您应该使用subversion存储库布局约定将分支与常规目录分开，svn使用一些启发式方法使事情适用于日常用例。但所有这些都只是掩盖了一个非常糟糕和有限的低级设计决策。能够实现基于存储库的差异(而不是基于目录的差异)是版本控制系统的基本和关键功能，并且极大地简化了内部结构，使得在此基础上构建更智能和有用的特性成为可能。您可以看到在扩展subversion方面所投入的大量工作，但是在合并解析等基本操作方面，它与当前的现代vcs有多么的差距。

现在，对于那些仍然相信Subversion在可预见的未来足够优秀的人，我有一个发自内心的不可知论的建议:

Subversion永远不会赶上从RCS和CVS的错误中吸取教训的新型vcs;这在技术上是不可能的，除非他们从头开始重新配置存储库模型，但这样就不是真正的SVN了，不是吗?不管你认为自己有多不具备现代VCS的能力，你的无知也无法保护你远离Subversion的陷阱，其中许多情况在其他系统中是不可能或很容易解决的。

很少有解决方案的技术劣势像svn一样明确，当然我永远不会对win-vs-linux或emacs-vs-vi发表这样的观点，但在这种情况下，它是如此明确，而源代码控制是开发人员武器库中如此基本的工具，我觉得必须明确地说明这一点。不管出于组织原因使用svn的需求如何，我恳求所有svn用户不要让他们的逻辑思维构建一个错误的信念，即更现代的vcs只对大型开源项目有用。不管您的开发工作的性质如何，如果您是一名程序员，那么如果您学习如何使用设计更好的vcs(无论是Git、Mercurial、Darcs还是许多其他类型的vcs)，您将成为一名更有效的程序员。