您最喜欢什么版本控制系统?[关闭]


41

与实际确定“最佳”尝试相比,这更是一个讨论问题,因为这显然会因组织的需求而异。我对支持不同类别(集中式,分布式,开放式与专有等)的不同系统的论点感到好奇。

那么,您认为最好的版本控制系统是什么?


1
en.wikipedia.org/wiki/Comparison_of_revision_control_software是一个很好的比较表。讨论问题...社区Wiki?
克里斯(Chris

4
第一个发布名称的人得到代表。这应该是社区Wiki。
Takehin 2010年


没注意到这已经是社区Wiki
Takehin 2010年

Answers:


81

水星

由于它具有分支和合并代码的先进能力,因此它是我使用过的最好的工具。整个DVCS范例非常有意义。我没有使用过Git,但我想它也可以使用。


我已经尝试过Mercurial了,因为我已经尝试了3个中的2个。并且由于Google Code支持它……
TheLQ 2010年

2
如果您使用的是Netbeans,Mercurial很不错。IDE集成是完美的。
Seen Osewa's

4
我更喜欢Mercurial只是因为TortoiseHg比TortoiseGit更成熟:-)(Windows的整体体验在Mercurial中也要好得多)
Dean Harding 2010年

+1,我建议使Mercurial变得更大胆(如Gaurav的回答)
Tim Post

水星很甜。我和我的团队已经使用了大约2个月,与SVN相比,这是新鲜空气。
加里·威洛比

72

吉特

Git太棒了,我特别推荐给从事开源项目的任何人:在Git上为项目做一个小的一次性更改要容易得多,特别是如果它托管在GitHub上,则比处理e-邮寄有关SVN的补丁。

Windows用户需要注意的一个重大问题:Git的Windows工具虽然确实可以使用,但还不够完善。当我不得不使用Windows一段时间后,我尝试了使用Hg-Git集成工具试用Mercurial的Windows界面,以便可以使用我的Git存储库,并且发现它更易于使用。


5
我认为说git很难是很重要的。我真的很喜欢它,但这不是几天可以学习的东西。你必须使用它一段时间,上火,直到你介意开关... ;-)
凯尔本

1
@Khelben-是的,这是有道理的。但是,它在网络上似乎也有大量专门用于它的文献/文章/教程。我经常发现Git书问世了,Mercurial并不是那么多(这里使用Mercurial作为对比,因为它在很多方面都与Git相似)。不能说这是好是坏,但似乎人们正在使用它。
Rook

2
在Windows下可以使用msysgit。

1
我认为git,Mercurial等都很好,但是我之所以选择git是因为auf GitHub。GitHub感觉比同类站点更好,并且在那里托管了许多重要项目。GitHub大大降低了为开源做出贡献的障碍。
LennyProgrammers 2010年

2
Mercurial不需要书。
沃伦·P

24

警告:自从这篇文章以来,我发现Mercurial并喜欢它比SVN好得多。因此,该帖子与Pro SVN评论和常规的反DVCS有点过时了,但是反git的内容仍然很重要


我是SVN over Git 的粉丝。

为什么?因为SVN对于单个开发人员或小型团队来说要容易得多,并且git(尤其是msysgit)使我口中难受。

当我在一家小商店实习时,我在Windows上被介绍给git。我立即注意到与Github一起使用需要花费大量的工作。首先,我必须生成一个ssh私钥,将公钥粘贴到Github中,然后每次我要推送时都进行选区并打开我的私钥,这非常烦人。

我从来没有真正喜欢过删除整个存储库。我会承认我从未使用过任何大型软件,但是如果整个repo及其修订版都在我的HD上,我会害怕在Git中下载KDE的存储库。

然后就是一个令人困惑的提交过程。TMK,我必须首先“暂存”我要提交的所有文件(当您有很多文件时很烂,花了我一段时间找到手动命令暂存所有文件),然后执行提交,然后推送到主目录。回购(为什么要进行单独操作?!)。

您还拥有了not(!)非常有用的提交数据。哦,看,这是树2167a4934d0a4a7db0de和父级d7042abb4821d3faf600的提交14f74433245ae17aeeaa部分。到底是什么意思?我应该能够很快找到答案,而不必查阅一些奇怪的文档。

说到文档,至少在我使用它的时候,似乎一切都以linux man文件格式出现,IE对我来说令人困惑和无用。我很少能在文档中找到很多帮助,只能求助于google。

对于提交,我不喜欢的一件事是缺少版本号。现在我知道这是因为git的设计,但是任何软件都需要版本号。我仍然记得会弹出标记提交,上面写着“将版本更改为1.8.6”或类似内容,但是您仍然无法建立编号。对于我来说版本是1.8.6.5164(最后一部分是修订号)对我来说不仅仅是1.8.6的更多内容,而且还有一条注释说有些小改动,请尝试一下

由于特定于软件,Windows上的基本程序是msysgit,这是一个糟糕的界面。它锁定了我几次,界面可怕,而且CLI-GUI集成充其量也很不稳定。我周围的命令行迷甚至更讨厌gui。


现在让我们看一下SVN。而且由于我在Windows上并且拥有Google帐户,特别是TortoiseSVN和Google Code。

首先,完全的Shell集成可完成存储库上的所有工作(对于Linux人士,RabbitVCS也是一样),不需要主GUI。作为一个结帐,获取存储库很容易,不需要SSH(不记得Github是否需要SSH进行拉取),也没有完整的存储库+所有过去的提交都坐在HD上。

提交非常容易,主要是因为不需要SSH或暂存。您只需使用非常有用的全选选项(在我的msysgit版本中不可用)中检查所有想要的文件,输入提交消息,然后单击提交即可。然后,Google Code要求您提供登录信息(大多数客户端都存储该信息),并完成操作。简单,轻松且无需SSH

版本号?通过一些简单的代码,您可以在所有结帐中添加版本号和提交号,这使事情变得非常容易。您还会获得实际显示更改的可用版本号,例如1.8.6.5165比1.8.6.5164更新。

文档?好吧,很难说。乌龟有文件记录,但是我很长一段时间都没有提到官方文件,以至于我无法判断。读一本简单的入门指南对我来说就足够了。

合并是我无法比拟的。当其他人对我正在处理的文件进行更改时,我必须在Git中执行一次,但是在SVN中则不需要。


我会推荐哪一个?在大型团队中,git确实有其优势,主要是在其非线性开发周期中。在另一个项目中,我看到4个程序员从单独的分支开始,然后以非常奇怪的方式合并所有代码,这些代码以某种方式演变为最终的master分支。Github和msysgit为我真正喜欢的整个项目提供了一个非常不错的可视化工具。

对于单个开发人员或小型团队项目,由于不使用大多数Gits功能,而只有它的负面影响,所以SVN是最好的。简单是一件好事


6
与SVN合并存在很大风险(与git相比)。在任何比较中都要注意这一点很重要。
Khelben

5
为什么每次都需要“选拔”?这是关键代理。登录到计算机后,只需启动一次即可。您添加了密钥,就完成了。(而且,可以通过将密钥文件与pageant关联并将其添加到启动文件夹中来使它变得更加容易。登录后,它会弹出对话框,提示您输入密码。)
Frank Shearar 2010年

3
@Thorbjoern @弗兰克·希勒(Frank Shearer):我认为您说的是“您可以做到这一点,或者您可以做到这一点,而没有那些问题”,这一事实凸显了这一点:这些是解决问题的方法。与其他一些VCS无关。
史蒂文·埃弗斯

4
这个答案让我感到震惊,因为很多抱怨和抱怨是发件人显然没有花时间去理解的。我在linux和Windows上都花费了大量时间在git和svn上,并将证明git在概念,数据模型,易懂性和实用性方面都大大优于svn。
gahooa 2010年

4
@TheLQ不。这根本不是“您的Linux心态”。设置非常简单,而且有据可查,PuTTY是一个出色的Windows应用程序套件,它使操作真的非常简单。如果您正在通过任何公共网络进行操作,则实际上应该对代码传输进行加密。Windows用户认为他们太愚蠢以至于无法学习如何使用他们应该使用的工具,这是侮辱。我不是在要求人们精打细算。我要他们加密重要信息。
Frank Shearar 2010年

22

Q4TD的以下引用对我来说几乎可以总结一下:

“我一直喜欢Git,直到尝试为止。现在我爱水星了。”

        — Tor Norbye,Java Posse播客

另外,hgsubversion是Linux的一个很好的subversion客户端(我通常使用命令行,而Windows则通常使用TortoiseSVN)。最大的优点是:.svn每个文件夹中没有子文件夹,仅.hg在顶层有一个子文件夹。

更新:响应Alex在评论中的要求,“更多地说明git为什么不适合您,以及Mercurial如何更好地工作”:

我不会说Git 不适用于我,但是Murcurial的IMO效果更好。

简而言之,这是Mercurial:

替代文字

这是Git:

替代文字

而且我断言Mercurial可以完成大多数开发人员需要做的所有事情,而无需查阅手册来弄清楚如何做日常工作。

诚然,我只是偶尔使用过Git,但是编程社区一直在争夺Ruby和Python之类的语言,部分原因是它们的简洁和优雅,而Git感觉就像是由骆驼委员会设计的骆驼。

ah,现在看看你做了什么?到处都有rant怒。前进,没什么可看的...没什么可看的...

更新2:我刚遇到另一条推文

“一旦掌握了分支是映射希尔伯特空间子流形的同胚内爆函数的基本概念,Git就变得更加容易。”


曾经尝试过RabbitVCS吗?
TheLQ's

不,但是我使用的是KDE,而不是Gnome,因此无论如何它都不适合我。我偶尔会在Linux上使用图形化SVN客户端,但只有在做一些深奥的事情(例如浏览存储库或比较以前的修订版)时才使用。不用于简单的添加/删除/提交/日志内容。命令行速度更快。
埃文(Evan)2010年

2
您能否说说为什么git不适合您,以及Mercurial如何更好地工作?读起来会很有趣。
Alex

我非常确定Git描绘缺少6英寸长的直剃刀……
Tim Post

2
@Tim:变基?可能在另一边。
艾伦·皮尔斯

14

我没有一个单一的“最佳”版本控制系统,而是一个单一的最佳VCS范例。

我使用了多个不同的集中版本控制系统和多个不同的分布式版本控制系统。我可以毫不犹豫地说,没有人应该对自己施加CVCS。

我不在乎您选择哪种 DVCS(我最喜欢的是Git),但是请您帮个忙并使用DVCS。例如:您将更加灵活。DVCS可以轻松地模拟CVCS工作流程(永远不要分叉存储库,而将本地存储库仅视为chache,而不是独立的分叉),而相反则是不可能的。虽然从逻辑上讲,这样做仿真随身携带一些开销(实际上它),我仍然觉得它更容易使用(更不用说更高性能由于本地缓存)比任何我已经使用了CVCSs的。


3
这是一个很好的答案。没有任何一个“最佳” VCS,但我完全同意应该使用DVCS。
尼克·霍奇斯

让我的为DVCS,但请保持映射Hilbert空间子流形的同胚内爆函数。Ergo,Mercurial。
沃伦·P

11

不能说我遇到了Best版本控制软件,但是我可以告诉您不要使用VSS和MKS。两只狗都应该不惜一切代价避免。


7

我不会说最好的,而是具有非常有趣的功能和概念的。

Fossil是一个基于SQLite数据库作为存储库的分布式版本控制,错误跟踪和Wiki项目。


5

Team Foundation服务器

因为:

  1. 这是一个很好的,可靠的VCS。(无论如何我都不认为它是最好的,但是它有很多优点。)
  2. 它内置于Visual Studio中的内置任务和错误跟踪功能可帮助我保持专注并了解在一个地方进行所有工作所需的内容(自动将检查应用于错误或任务并关闭它非常好,尽管您可以获取其他系统/ eclipse / etc的插件来执行此操作。)
  3. 它将任务/错误跟踪/项目直接集成到Project Server中,因此我几乎不需要保持项目计划或时间表最新。Project Server中对Project的更新会自动作为任务过滤到TFS和Visual Studio中,以便我自动查看。

2
我很好奇您对工作流只限于Visual Studio进行几乎所有开发工作的感觉。另外,您是否需要为TFS做任何基础架构设置?我的经验与您的情况相反:#1-VCS并不易于使用,常常不可靠,并且脱机模式是由satan自己创建的。#2与其他工具相比,内置的任务和错误跟踪比较麻烦,因此#3对我们而言无关紧要,并且创建了重复的工作。我现在已经使用了3次不同的时间,每次都具有相同的不良结果。
乔丹

1.我同意离线模式下的吸吮。虽然我在网上完全没有很多问题,但是我始终保持联系。实际上,许多VCS控件(尤其是带有文件夹重映射的控件)实际上隐藏在菜单的深处。那是你的问题吗?2.肯定比较麻烦,但是可以节省与Project Server集成的团队的整体工作量。3.如何创建重复的工作?您是否正在复制项目服务器和TFS中的任务?2007年有一个开源插件,2010年有一个beta版,可以使它们彼此同步。
瑞安·海斯

1
它确实使我无法使用VS,但我们完全是.NET商店。不过,我在家里的Java项目中使用了TFS。在svnbridge.codeplex.com上尝试使用SVNBridge,它使您可以在TFS中使用Tortoise。如果您使用Tortoise(像大多数Java,ruby,非.net人士一样),那么它应该可以帮助您处理其他项目中的工作流程。
瑞安·海斯

4

在我悠久的历史中,我曾使用过多种版本控制系统:

  • RPPT-(打孔纸带卷)。在鞋盒里。我不是在开玩笑。
  • PVCS-(Polytron版本控制系统)。我使用的第一个真正的VCS。
  • SCCS-很久以前,我不记得有什么特别好或坏的事情。
  • 正如其他人指出的那样,RCS宁愿吸汗的驴球。
  • CVS-与2个以上的程序员一起使用时,这只是一个痛苦。最佳功能:rcs2cvs。
  • VSS-当星期二破坏整个存储库时,它可以工作。
  • Perforce-花费比我的车还多。VCS本身是可以接受的,但是控制其使用各个方面的傻瓜IT人士永远不会将其放在我的“首选”列表中。
  • SVN-分支和合并是一个bit子,但总的来说,它比以前任何一个都要好。不太好,有许多微小的未完成更改正在等待审查。
  • Mercurial-我喜欢我几乎没有经验。我可以在下一个项目中尝试。
  • Git-从来没有机会使用它。

尽管一对夫妇感到恐惧,但大多数都是“罚款”。他们没有妨碍我。只要一种工具不会使我的生活变得更加困难,我就不会介意。

真正的事情是了解每个优点和缺点。了解目标环境:

  • 分布式或本地
  • 小团队还是大团队
  • 是否托管vcs服务
  • 轻松集成到其他工具

Joel还得出了一个重要的观察结果:学习该工具及其真正的使用模型。他竭尽全力地试图使水星的表现像颠覆。


1
如果只是关于VSS的评论是个玩笑...请避免像瘟疫一样。
DevSolo

啊,PVCS,回想起的回忆:)那真是个垃圾。
亨利2010年

该列表使我想起了基于“打脚”的语言。+1
Orbling 2010年

我确实记得关于SCCS的坏事,但是它通常是可用的。我确实记得曾经尝试过与SCCS和其他程序员同时处理文件,这就是为什么当我看到CVS时就爱上它了。
David Thornley 2010年

Visual SourceSafe,一个VCS,特别适合希望用勺子挖眼睛的程序员。
Mark Booth,

2

我们在办公室使用的一种较新的系统是Plastic SCM(http://www.plasticscm.com/)。它对我们的小型团队非常有效,并且使我们可以对源代码管理的各个方面进行一些控制。


1

SCCS

或者,如果您碰巧在过去的38年中没有住过洞穴,那就去CSSC吧

认真地说,我公司正在使用TeamWare,这是一种基于SCCS的伪DVCS。

不,我不是在开玩笑。

Sun仅在几年前从TeamWare转换为Mercury。现在,您应该了解Java为什么运行如此缓慢。


1

MPW:好吧,尽管我付出了很大的努力,但我还是无法对其进行评论。

那是我上高中时学习编程的时候,当时唯一真正免费的C ++编译器是Macintosh Programming Workbench,我将它保存在一个zip磁盘上,然后弹出实验室中可用的Performa。

MPW附带了数十种工具(没有一个是重新编辑的,这是单独下载的),其中一个是版本控制实用程序。它弹出并打开一个带有单行文本的小窗口,您需要将项目或文件拖放到该窗口上。它没有我能找到的文档,考虑到其他所有东西似乎都具有出色的文档,这是不寻常的,因此我从来没有想出如何使用它。

那是我第一次使用VC,最后很长时间了。现在,我将git用于所有内容。


投影仪!在大学期间,我做一份兼职工作(删掉了)。美好的时光。
RyanWilcox

0

RCS-版本控制系统

独奏编码变得如此简单。


你在开玩笑吧,Xepoch?请上帝开玩笑。
Marc W 2010年

你们在逗我笑。实际上,我确实使用RCS,但仅用于我的个人网站&c。我只是在开玩笑地谈论将其用于主要开发,但是我看到它仅在共享开发Unix系统上使用(而不是CVS)。老实说,我们对此没有任何问题,但是除了单一服务器功能之外,它不提供其他任何服务。
JE队列

1
@Xepoch,学习Git或Mercurial可能会更好-DCVS非常适合单独开发。
Fishtoaster

1
您知道RCS的真正好处是什么吗?您可以将所有RCS,v文件放入适当的目录结构中,并且CVS储备库几乎已准备就绪。然后有很多工具可以将CVS转换为您喜欢的任何现代系统,例如Mercurial。
David Thornley 2010年

@Xepoch,备份分布式vcs的便捷性无与伦比。

0

至少对于Unix / Linux系统,不是ClearCase(也许对于Windows,安装程序更容易)。对我来说,学习新工具Perforce比升级我们的ClearCase服务器要容易得多。

我目前在工作中使用Perforce,我喜欢它,但我不知道它是否是最好的。设置命令行环境和Perforce Server有点尴尬,但是使用Visual Client相当容易。我想认为用户在日常工作中有一个相对轻松的时间;只是初始设置需要一些工作。


0

我曾经使用过Visual SourceSafe并讨厌它,但是它总比没有好,但是效果不佳。在过去的几年中,使用了由Qumasoft.com编写的,由程序员Jim Voris拥有和支持的QCVS。简单的图形用户界面,价格便宜,良好的支持。

只是做工作。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.