我应该使用SVN还是Git？

Question

我正在开始一个新的分布式项目.我应该使用SVN还是Git,为什么？

Answer 1

SVN是一个回购和很多客户.Git是一个拥有大量客户回购的回购,每个回购都有一个用户.它被分散到人们可以在本地跟踪自己的编辑而无需将内容推送到外部服务器的程度.

SVN被设计为更加重要的地方,Git基于每个用户拥有自己的Git repo,并且那些repos推送更改回到中央.出于这个原因,Git为个人提供了更好的本地版本控制.

同时你可以选择TortoiseGit,GitExtensions(如果你在github上托管你的"中央"git-repository,他们自己的客户端 - 用于Windows的GitHub).

如果你想要退出SVN,你可能想要评估一下Bazaar.它是具有此分布式元素的下一代版本控制系统之一.它不依赖于POSIX,因此有本机Windows版本,它有一些强大的开源品牌支持它.

但是你甚至可能还不需要这些功能.了解分布式VCS的功能,优缺点.如果您需要的不仅仅是SVN优惠,请考虑一个.如果不这样做,您可能希望坚持使用SVN(当前)卓越的桌面集成.

Answer 2

我从来不理解"git在Windows上不好"的概念; 我只在Windows下开发,我从来没有遇到任何git问题.

我肯定会推荐git over subversion; 它的功能多得多,并且允许"颠覆式开发"以颠覆从未真正实现过的方式.它几乎可以在任何可以想象的平台上使用,并且具有比您可能使用的功能更多的功能.

Answer 3

这是我对一些重复问题的回答的副本,此后删除了关于Git与SVN(2009年9月).

更好？除了通常的链接WhyGitIsBetterThanX,它们是不同的:

一个是基于分支和标签的廉价副本的中央VCS另一个(Git)是基于修订图的分布式VCS.另请参阅VCS的核心概念.

第一部分产生了一些错误的评论,假装两个程序(SVN和Git)的基本目的是相同的,但它们的执行方式完全不同.
为了澄清SVN和Git之间的根本区别,让我重新说一下:

• SVN是版本控制的第三个实现:RCS,然后是CVS,最后是SVN管理版本化数据的目录.SVN提供了VCS功能(标签和合并),但它的标签只是一个目录副本(就像一个分支,除了你"不应该"触摸标签目录中的任何东西),它的合并仍然很复杂,目前基于meta -data添加以记住已经合并的内容.

• Git是一个文件的内容管理(由合并文件的工具),演变成一个真正的版本控制系统的基础上,DAG(有向无环图的提交,其中分支数据更历史的一部分(而不是数据本身) ),标签是真正的元数据.

要说它们不是"根本上"不同,因为你可以达到同样的目的,解决同样的问题,是......在很多层面上都是假的.

• 如果你有很多复杂的合并,用SVN做它们会更长,更容易出错.如果你必须创建许多分支,你将需要管理它们并合并它们,再次使用Git比使用SVN更容易,特别是如果涉及大量文件(速度变得很重要)
• 如果你正在进行一项正在进行的工作的部分合并,你将利用Git临时区域(索引)只提交你需要的东西,存储其余的,然后继续另一个分支.
• 如果您需要离线开发...与Git一起使用您总是"在线",使用您自己的本地存储库,无论您想要与其他存储库一起使用的工作流程.

关于那个旧(删除)答案的评论仍然坚持:

VonC:你在实现方面存在差异,实施中的基本差异(差异非常基本,我们都明确同意).
它们都是用于相同目的的工具:这就是为什么许多以前使用过SVN的团队已经成功地将它转储为Git.
如果他们没有解决同样的问题,那么这种可替代性就不存在了.

,我回答说:

"可替代性"......有趣的术语(用于计算机编程).
当然,Git几乎不是SVN的子类型.

您可以使用两者来实现相同的技术功能(标记,分支,合并),但Git不会妨碍您,并且您可以专注于文件的内容,而无需考虑工具本身.

您当然不能(总是)只是用Git替换SVN"而不改变该程序的任何理想属性(正确性,执行任务,......)"(这是对上述可替代性定义的引用):

• 一个是扩展修订工具,另一个是真正的版本控制系统.
• 一个适合中小型单片项目,具有简单的合并工作流程和(不太多)并行版本.SVN就足够用于此目的,您可能不需要所有Git功能.
• 另一个允许基于多个组件的中型到大型项目(每个组件一个repo),在复杂的合并工作流中多个分支之间合并大量文件,分支中的并行版本,改进合并等等.你可以用SVN做到这一点,但你最好用Git.
  SVN无法使用任何合并工作流管理任何大小的任何项目.Git可以.

同样,它们的性质根本不同(然后导致不同的实现,但这不是重点).
一个看到版本控制作为目录和文件,另一个只看到文件的内容(以至于空目录甚至不会在Git中注册!).

一般的最终目标可能是相同的,但您不能以相同的方式使用它们,也不能解决同一类问题(范围或复杂性).

Answer 4

SVN的两个主要优点很少被引用:

1. 大文件支持.除了代码,我使用SVN来管理我的主目录.SVN是唯一没有阻塞我的TrueCrypt文件的VCS(分布式或非分布式)(如果有另一个VCS可以有效处理500MB +文件,请纠正我).这是因为差异比较是流式传输的(这是非常重要的一点).Rsync是不可接受的,因为它不是双向的.

2. 部分存储库(子目录)结帐/签入.Mercurial和bzr不支持这一点,而且git的支持是有限的.这在团队环境中很糟糕,但如果我想从我家里的另一台计算机上查看一些内容,这是非常宝贵的.

只是我的经历.

Answer 5

在做了更多的研究,并审查了这个链接:https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(以下一些摘录):

• 它的速度非常快.没有其他我使用的SCM能够跟上它,我已经使用了很多,包括Subversion,Perforce,darcs,BitKeeper,ClearCase和CVS.
• 它是完全分布的.存储库所有者无法决定我的工作方式.我可以在笔记本电脑上断开连接时创建分支并提交更改,然后将其与任意数量的其他存储库同步.
• 可以通过许多媒体进行同步.SSH通道,通过WebDAV通过HTTP,通过FTP或发送包含要由消息接收者应用的补丁的电子邮件.中央存储库不是必需的,但可以使用.
• 分支甚至比Subversion更便宜.创建分支就像将41字节文件写入磁盘一样简单.删除分支就像删除该文件一样简单.
• 与Subversion不同,分支带有完整的历史记录.无需执行奇怪的副本并浏览副本.使用Subversion时,我总是发现在创建分支之前查看分支上的文件的历史记录很困​​难.来自#git:spearce:我对页面中的SVN一无所知.我在SVN上创建了一个分支,浏览历史记录显示整个历史记录中的一个文件
• Git中的分支合并更简单,更自动.在Subversion中,您需要记住您合并的最后一个修订版本,以便生成正确的合并命令.Git会自动执行此操作,并始终正确执行此操作.这意味着将两个分支合并在一起时犯错的可能性较小.
• 分支合并被记录为存储库的正确历史记录的一部分.如果我将两个分支合并在一起,或者如果我将一个分支合并回到它所来自的主干中,则该合并操作被记录为由我执行的重新存储历史的一部分,以及何时.当日志中存在合并时,很难对谁进行合并提出异议.
• 创建存储库是一项简单的操作:mkdir foo; cd foo; git init就是这样.这意味着我现在为所有东西创建一个Git存储库.我倾向于每个类使用一个存储库.这些存储库中的大多数都在磁盘下不到1 MB,因为它们只存储讲义,家庭作业和我的LaTeX答案.
• 存储库的内部文件格式非常简单.这意味着修复很容易,但更好,因为它非常简单,很难被破坏.我认为没有人曾经有过Git存储库被破坏.我已经看到Subversion与fsfs腐败本身.我已经看到Berkley DB损坏了太多次信任我的代码到Subversion的bdb后端.
• Git的文件格式非常擅长压缩数据,尽管它是一种非常简单的格式.Mozilla项目的CVS存储库大约为3 GB; 它在Subversion的fsfs格式中约为12 GB.在Git中它大约300 MB.

阅读完所有这些之后,我确信Git是可行的方法(虽然存在一点学习曲线).我也在Windows平台上使用过Git和SVN.

在阅读上述内容之后,我想听听其他人的意见吗？

Answer 6

我会建立一个Subversion存储库.通过这种方式,各个开发人员可以选择是否使用Subversion客户端或Git客户端(with git-svn).使用git-svn并不能为您提供完整Git解决方案的所有好处,但它确实为各个开发人员提供了对其自身工作流程的大量控制.

我相信Git在Windows上的运行时间与在Unix和Mac OS X上的运行时间相对较短(因为你问过).

Subversion具有出色的Windows工具,例如用于Explorer集成的TortoiseSVN和用于Visual Studio集成的AnkhSVN.

Answer 7

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

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

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

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

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

Answer 8

当然svn,因为Windows最多是世界上的二等公民git(更多细节见http://en.wikipedia.org/wiki/Git_(software)#Portability).

更新:抱歉链接已损坏,但我已经放弃尝试使用包含括号的URI.[现在链接修复.-ed]

Answer 9

没有真正回答你的问题,但如果你想要分布式版本控制的好处- 听起来像你这样做 - 而你正在使用Windows我认为你最好使用Mercurial而不是Git作为Mercurial有更好的Windows支持.Mercurial也有Mac端口.

Answer 10

如果您的团队已经熟悉cvs或svn等版本和源代码控制软件,那么,对于一个简单的小项目(例如您声称的那样),我建议您坚持使用SVN.我对svn很满意,但对于我在django上做的当前电子商务项目,我决定使用git(我在svn-mode中使用git,也就是说,我使用集中式仓库来推送和拉动来自至少与其他一个开发者合作).另一个开发人员对SVN感到满意,虽然其他人的体验可能不同,但我们两个人都非常抱怨这个小项目的git.(如果重要的话,我们都是核心Linux用户.)

当然,您的里程可能会有所不同.

Answer 11

重点是,Git是一个分布式VCS,而Subversion是一个集中式VCS.分布式VCS有点难以理解,但有许多优点.如果你不需要这个优势,Subversion可能是更好的选择.

另一个问题是工具支持.您计划使用的工具可以更好地支持哪种VCS？

编辑:三年前我这样回答:

Git目前仅通过Cygwin或MSYS在Windows上运行.Subversion从一开始就支持Windows.由于Windows的git-solutions可能对您有用,因此可能存在问题,因为Git的大多数开发人员都使用Linux并且从一开始就没有可移植性.目前我更喜欢在Windows下使用Subversion进行开发.在几年内,这可能是无关紧要的.

现在世界发生了一些变化.Git现在在Windows上有很好的实现.虽然我在Windows上没有经常测试(因为我不再使用这个系统),但我非常有信心,所有主要的VCS(SVN,Git,Mercurial,Bazaar)现在都有适当的Windows实现.SVN的这个优势已经消失.其他要点(Centralized vs. Distributed和检查工具支持)保持有效.

Answer 12

我会选择SVN,因为它更广泛传播并且更为人所知.

我猜,Git对Linux用户会更好.