Git，Mercurial和Bazaar的相对优缺点是什么？[关闭]

这里的人们认为Git，Mercurial和Bazaar的相对优势和劣势是什么？

在相互考虑并针对诸如SVN和Perforce之类的版本控制系统进行考虑时，应考虑哪些问题？

在计划从SVN到这些分布式版本控制系统之一的迁移时，您将考虑哪些因素？

Git速度非常快，扩展性非常好，并且其概念非常透明。不利的一面是它的学习曲线比较陡峭。有可用的Win32端口，但不是一流的公民。Git向用户公开哈希作为版本号；这提供了保证（因为单个散列始终指的是完全相同的内容；攻击者无法在不被检测到的情况下修改历史记录），但是对于用户而言可能很麻烦。Git具有跟踪文件内容的独特概念，即使这些内容在文件之间移动，并且将文件作为第一级对象查看，但不跟踪目录。git的另一个问题是它有很多操作（例如变基），这样就很容易修改历史记录（从某种意义上说，哈希所引用的内容永远不会改变，但是对该哈希的引用可能会丢失）；一些纯粹主义者（包括我自己）不太喜欢。

Bazaar相当快（对于具有浅历史记录的树来说非常快，但是目前随着历史记录的长度扩展性很差），并且对于那些熟悉传统SCM（CVS，SVN等）命令行界面的人来说易于学习。Win32被其开发团队视为一流的目标。它具有用于不同组件的可插拔体系结构，并经常替换其存储格式。这使他们可以引入新功能（例如更好地支持与基于不同概念的修订控制系统集成）并提高性能。Bazaar团队认为目录跟踪和重命名支持一流的功能。全局唯一的修订ID标识符可用于所有修订，而树形本地修订号（标准修订号，（类似于svn或其他更常规的SCM使用的内容）代替内容散列来标识修订。Bazaar支持“轻量结帐”，其中历史记录保存在远程服务器上，而不是复制到本地系统中，并在需要时通过网络自动引用。目前，这在DSCM中是唯一的。

两者都有某种形式的SVN集成。但是，bzr-svn比git-svn的功能要强大得多，这在很大程度上是由于为此目的引入了后端格式修订版。[自2014年起更新：第三方商业产品SubGit在SVN和Git之间提供了双向接口，其保真度可与bzr-svn相媲美，并且更加精致；我强烈建议在预算和许可限制允许的情况下，使用它而不是使用git-svn。

我没有广泛使用Mercurial，因此无法对其进行详细评论-除非注意到它像Git一样，具有针对修订的内容哈希寻址；与Git一样，它也不会将目录视为一流对象（并且无法存储空目录）。但是，它比Git以外的任何其他DSCM都要快，并且IDE集成（尤其是Eclipse）要比其任何竞争对手都要好得多。鉴于其性能特征（仅略低于Git的性能）以及出色的跨平台和IDE支持，Mercurial可能对于拥有大量以win32为中心或受IDE约束的成员的团队具有吸引力。

从SVN迁移的一个担心是，SVN的GUI前端和IDE集成比任何分布式SCM都更加成熟。另外，如果您当前在SVN中大量使用预提交脚本自动化功能（即要求在进行提交之前必须通过单元测试），则可能要使用类似于PQM的工具来自动执行对共享分支的合并请求。

SVK是使用Subversion作为后备存储的DSCM，并且与以SVN为中心的工具具有很好的集成。但是，它的性能和可伸缩性比任何其他主要DSCM（甚至是Darcs）都要差得多，因此对于历史长度或文件数量可能会增大的项目，应避免使用它。

[关于作者：我使用Git和Perforce进行工作，使用Bazaar进行我的个人项目并作为嵌入式库；我雇主组织的其他部门大量使用Mercurial。在以前的生活中，我围绕SVN构建了很多自动化功能。在此之前，我曾经在GNU Arch，BitKeeper，CVS和其他方面有经验。Git一开始就很反感-感觉像GNU Arch一样，它是一个概念繁重的环境，而不是为符合用户选择的工作流而构建的工具包-但从那时起，我就变得非常满意它]。

Ogre 3D项目的Steve Streeting刚刚（9/28/2009）发表了一个有关此主题的博客条目，他在其中对Git，Mercurial和Bazaar进行了非常出色的对比。

最后，他发现了三者的优势和劣势，没有明显的赢家。从好的方面来说，他给出了一个很好的表，可以帮助您决定选择哪一个。

它是一个简短的阅读，我强烈推荐它。

这里的人们认为Git，Mercurial和Bazaar的相对优势和劣势是什么？

在我看来，Git的优势在于其简洁的底层设计和非常丰富的功能集。我认为它也为多分支存储库和管理繁重的分支工作流提供了最佳支持。它非常快，并且存储库大小很小。

它具有一些有用的功能，但需要花费一些精力才能使用它们。其中包括工作区和存储库数据库之间的可见中间阶段ara（索引），它可以在更复杂的情况下更好地进行合并解析，增量提交和使用脏树进行提交；使用相似性试探法来检测重命名和副本，而不是使用某种文件ID来跟踪它们，这种方法效果很好，并且可以怪罪（注释），这不仅可以跟踪整个文件中的代码移动，而且还可以跟踪大量的重命名。

它的缺点之一是MS Windows支持滞后并且不完整。另一个可察觉的缺点是，它的记录不如Mercurial那样，并且不如竞争对手容易使用，但它会发生变化。

在我看来，Mercurial的优势在于其良好的性能和较小的存储库大小，以及对MS Windows的良好支持。

在我看来，主要缺点是本地分支机构（单个存储库中的多个分支机构）仍然是二等公民，并且以奇怪且复杂的方式实现标签。同样，它处理文件重命名的方式也不是很理想（但是这种变化已经改变了）。Mercurial不支持章鱼合并（有两个以上的父母）。

从我所听到和阅读的Bazaar的主要优点中，它可以轻松支持集中式工作流（这也是缺点，因为集中式概念在不应该出现的地方可见），跟踪文件和目录的重命名。

它的主要缺点是具有较长非线性历史的大型存储库的性能和存储库大小（至少对于不太大的存储库，性能有所改善），默认范式是每个存储库一个牧场（尽管您可以将其设置为共享数据） ，以及集中化的概念（但这也是我所听到的变化）。

Git用C，shell脚本和Perl编写，并且可以编写脚本。Mercurial用C（性能代表核心）和Python编写，并提供扩展API。Bazaar用Python编写，并提供扩展API。

在相互考虑并针对诸如SVN和Perforce之类的版本控制系统进行考虑时，应考虑哪些问题？

诸如Subversion（SVN），Perforce或ClearCase之类的版本控制系统是集中式版本控制系统。Git，Mercurial，Bazaar（以及Darcs，Monotone和BitKeeper）是分布式版本控制系统。分布式版本控制系统允许更广泛的工作流。他们允许使用“准备就绪时发布”。他们为分支和合并以及繁重的工作流提供了更好的支持。您无需信任具有提交访问权限的人员，便可以轻松地从他们那里获得捐款。

在计划从SVN到这些分布式版本控制系统之一的迁移时，您将考虑哪些因素？

您可能要考虑的因素之一是对SVN吸引力的支持。Git具有git-svn，Bazaar具有bzr-svn，Mercurial具有hgsubversion扩展名。

免责声明：我是Git用户和少量时间贡献者，并查看（并参与git邮件列表）。我仅从Mercurial和Bazaar的文档，关于IRC和邮件列表的各种讨论以及比较各种版本控制系统的博客文章和文章（其中有些列在Git Wiki的GitComparison页面上）中了解Mercurial和Bazaar 。

InfoQ有一个很好的比较。

水星和集市在表面上非常相似。它们都提供基本的分布式版本控制，例如在脱机提交和合并多个分支中，都使用python编写，并且都比git慢。深入研究代码后，会有很多差异，但是，对于日常的日常任务，它们实际上是相同的，尽管Mercurial似乎更有动力。

好吧，Git并不是针对没有经验的人。它比Mercurial和Bazaar都快得多，并且是为管理Linux内核而编写的。它是三者中最快的，也是三者中最强大的，相当可观。Git的日志和提交操作工具无与伦比。但是，它也是最复杂和最危险的使用方式。丢失提交或破坏存储库非常容易，尤其是如果您不了解git的内部工作原理时。

看看Python开发人员最近进行的比较：http : //wiki.python.org/moin/DvcsComparison。他们基于以下三个重要原因选择了Mercurial：

选择Mercurial是出于三个重要原因：

• 根据一项小型调查，与Bazaar或Git相比，Python开发人员对使用Mercurial更感兴趣。
• Mercurial用Python编写，这与python-dev倾向于“吃自己的狗粮”的趋势一致。
• Mercurial明显比bzr快（它比git慢，尽管差别小得多）。
• 相对于Bazaar，对于SVN用户而言，Mercurial更容易学习。

（来自http://www.python.org/dev/peps/pep-0374/）

Sun对git，Mercurial和Bazaar进行了评估，以替代Solaris代码库的Sun Teamware VCS。我觉得这很有趣。

集市中一个非常重要的丢失内容是cp。您不能像SVN中那样拥有多个共享相同历史记录的文件，请参见此处和此处的示例。如果您不打算使用cp，则bzr是svn的绝佳替代品，并且非常易于使用。

我使用Bazaar一段时间了，我很喜欢它，但那只是较小的项目，即使那样也很慢。如此简单易学，但不是超级快。它是非常x平台的。

我目前非常喜欢Git，因为1.6版在使用命令方面使其与其他VCS更加相似。

我认为我使用DVCS的主要区别在于：

1. Git具有最活跃的社区，通常会看到有关Git的文章
2. GitHub真的很糟糕。Launchpad.net可以，但是没有像Github的乐趣
3. Git的工作流程工具数量众多。它已集成到各处。Bzr有一些功能，但维护数量却很少或保持得很好。

总而言之，当我在DVCS上学习时，Bzr很棒，但是现在我对Git和Github感到非常满意。

这是一个很大的问题，很大程度上取决于上下文，这将使您花费大量时间在这些小文本框中之一中键入内容。同样，当用于大多数程序员的常用内容时，所有这三种方法看起来都基本相似，因此，即使要了解差异，也需要一些相当深奥的知识。

如果您可以将对这些工具的分析分解为更具体的问题，则可能会得到更好的答案。

集市比IMHO更容易学习。Git在github.com上有很好的支持。

我认为您应该尝试同时使用两者，并确定最适合您的情况。

这里的人们认为Git，Mercurial和Bazaar的相对优势和劣势是什么？

这是一个非常开放的问题，与烈火有关。

Git是最快的，但是这三个都足够快。Bazaar是最灵活的（它对SVN存储库具有透明的读写支持），并且非常关注用户体验。水星在中间。

这三个系统都有很多粉丝。我个人是集市的粉丝。

在相互考虑并针对诸如SVN和Perforce之类的版本控制系统进行考虑时，应考虑哪些问题？

前者是分布式系统。后者是集中式系统。另外，Perforce是专有的，而其他所有语言都是免费的。

集中式与分散式的选择比您在其类别中提到的任何系统都要重要得多。

在计划从SVN到这些分布式版本控制系统之一的迁移时，您将考虑哪些因素？

首先，缺少TortoiseSVN的良好替代品。尽管集市正在自己工作 Tortoise变体，但是截至2008年9月，它尚不存在。

然后，对关键人员进行培训，使其了解如何使用去中心化系统将影响他们的工作。

最后，与其他系统集成，例如问题跟踪器，夜间构建系统，自动测试系统等。

您的主要问题将是这些是分布式 SCM，因此需要对用户的思维方式进行一些更改。一旦人们习惯了这个想法，技术细节和使用模式就会就位，但是不要低估最初的障碍，尤其是在公司环境中。请记住，所有问题都是人的问题。

ddaa.myopenid.com顺便提到了它，但我认为值得再次提及：Bazaar可以读写远程SVN存储库。这意味着您可以在本地使用Bazaar作为概念验证，而团队的其他成员仍在使用Subversion。

编辑：几乎所有的工具，现在有一些与SVN交互的方式，但我现在有切身体会git svn的作品非常好。我已经使用了几个月，几乎没有打ic。

Linus Torvalds在git上有很好的视频。他是Git的创建者，所以他提倡这点，但是在视频中，他解释了什么是分布式SCM，以及为什么它们比集中式SCM更好。有很多比较git（可以认为是Mercurial可以）和cvs / svn / perforce的比较。听众也有关于向分布式SCM迁移的问题。

我发现这种材料很有启发性，我被卖给了分布式SCM。但是，尽管莱纳斯（Linus）做出了种种努力，我的选择还是无情的。原因是bitbucket.org，我发现它比github更好（更慷慨）。

在此我要警告：Linus具有相当进取的风格，我认为他想变得有趣，但我没有笑。此外，如果您是分布式SCM的新手，并考虑从SVN迁移，那么该视频非常棒。

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

分布式版本控制系统（DVCS）解决的问题不同于集中式VCS。比较它们就像比较锤子和螺丝刀。

集中式VCS系统的设计目的是要有一个真正的源头，这是有福的，因此是好源。所有开发人员都从该源工作（签出），然后添加（提交）他们的更改，这些更改也同样受到祝福。CVS，Subversion，ClearCase，Perforce，VisualSourceSafe和所有其他CVCS之间的唯一真正区别是每种产品提供的工作流程，性能和集成。

分布式VCS系统的设计意图是一个存储库与任何其他存储库一样好，并且从一个存储库合并到另一个存储库只是另一种通信形式。关于应该信任哪个存储库的任何语义值都是通过过程而不是软件本身从外部施加的。

在使用一种类型或另一种类型之间的真正选择是组织-如果您的项目或组织需要集中控制，那么DVCS就不是首选。如果希望您的开发人员可以在整个国家/地区工作，而没有到中央存储库的安全宽带连接，那么DVCS可能是您的救星。如果两者都需要，您会感到震惊。