为什么Git比Subversion更好？

Question

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

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

Git如何改进Subversion？

Answer 1

Git并不比Subversion好.但也不会更糟.这不一样.

关键的区别在于它是分散的.想象一下,如果你是一名开发人员,你可以在笔记本电脑上进行开发,并希望拥有源代码控制,这样你就可以回到3个小时.

使用Subversion,您遇到了一个问题:SVN存储库可能位于您无法访问的位置(在您的公司中,目前您还没有Internet),您无法提交.如果要复制代码,则必须逐字复制/粘贴它.

有了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表现得更好,并有助于让我的生活更加健全.以下是一些小事:

1. Git有一个'干净'命令.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),这不会影响其他任何人.

Answer 4

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

简述:

• Git跟踪内容而不是文件
• 分支很轻,合并很容易,我的意思很简单.
• 它是分布式的,基本上每个存储库都是一个分支.在我看来,与Subversion相比,并发和协作开发要容易得多.它还使离线开发成为可能.
• 它没有强加任何工作流程,如上面链接的网站所示,Git可以实现许多工作流程.Subversion风格的工作流程很容易模仿.
• Git存储库的文件大小比Subversion存储库小得多.只有一个".git"目录,而不是几十个".svn"存储库(注意Subversion 1.7和更高版本现在使用像Git这样的单个目录.)
• 该临时区域是真棒,它可以让你看到你将提交更改,提交局部修改和做各种其他的东西.
• 当你进行"混乱"开发时,存储是非常宝贵的,或者只是想在你还在处理其他东西时(在不同的分支上)修复bug.
• 您可以重写历史记录,这对于准备补丁集和修复错误非常有用(在发布提交之前)
• ...还有很多更.

有一些缺点:

• 目前还没有很多优秀的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 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的要点是:

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

一个相对较大的项目的主要原因是由第3点创建的改进的沟通.其他是很好的奖金.

Answer 8

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

请阅读Google代码项目中使用Git开发

虽然Google Code本身就说Subversion,但您可以在开发过程中轻松使用Git.搜索"git svn"表明这种做法很普遍,我们也鼓励你尝试一下.

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

1. 我可以分布在几台机器上工作,提交和拉动它们
2. 我有一个中央 backup/public svn存储库供其他人查看
3. 他们可以自由地使用Git

Answer 9

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

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

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

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

Answer 10

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

Answer 11

关于SubVersion让我烦恼的一件事是它将自己的文件夹放在项目的每个目录中,而git只将一个放在根目录中.这不是什么大不了的事情,但是像这样的小事情加起来.

当然,SubVersion有Tortoise,[通常]非常好.

Answer 12

关于Subversion/GIT的David Richards WANdisco博客

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和SVN的实际用法,它可以让你了解Git与SVN相比可以做什么(或者更容易做).(从技术上讲,这是基于Easy Git,它是Git上的轻量级包装器.)

Answer 16

Git和DVCS一般非常适合开发人员彼此独立编码,因为每个人都有自己的分支.但是,如果您需要从其他人那里获得更改,她必须承诺使用当地的回购,然后她必须将该变更集推送给您,否则您必须将其从她手中取出.

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

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

Answer 17

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

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

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