Git，Hg或Bzr - 向新用户推荐哪个？

Question

我有一些朋友可能有兴趣学习使用版本控制系统来完成即将到来的硕士论文（Latex文档和各种编程）。我不是在谈论任何大而复杂的东西，只是用它来备份，查看旧版本和一些基本的分支和合并。

但是，我认为选择一个对初学者来说有点容易学习的东西是个好主意。所以问题是，你会向那些不熟悉这些东西的人推荐哪个版本控制系统？

我个人一直在使用Git和Mercurial，目前我认为我倾向于Mercurial。我没有尝试过Bazaar。

到目前为止，这是我对适合新用户的功能的印象：

的水银 的

优点：

• 修订编号
• 轻松签出旧提交，处理它并将其合并到
• 直接与mergetool轻松合并
• 易分支（？）
• 像glog这样的好插件

缺点：

• 分支和书签都可以用于Git所谓的分支 - 可能有点混乱
• 在执行命令时没有提供有关执行/错误的信息

的 GIT中 的

优点：

• 完全控制（至少给人一种印象）
• 出现问题时的详细帮助和信息

缺点：

• 一些困难的概念（如临时区域）
• 某些分支操作可能有点困难

的巴扎 的

没试过......

你怎么看？回答时请按good subjective guidelines here。

Answer 1

我从头开始教授版本控制的最后几个人是git（包括我12岁时的女儿）。我也教过新用户mercurial。

对于没有修订控制经验的人来说，两者都同样容易。对于那些被颠覆或CVS打破的人来说，git最初更难（尽管取决于他们是否愿意理解基本面而不是盲目地让事情发挥作用，git很容易）。

基于此，以及其他一些回应以及我个人的偏见，我认为git是最好的答案。仅在github上就有近200万个git存储库。它不会很快到来。

Answer 2

你认为是Mercurial专业人员之一 - 修订编号 - 被许多人认为是不利的。而你认为是git劣势 - 临时区域;困难的概念 - 被许多人认为是有利的。

所以这不是那么简单。

但是如果你问我 - Mercurial就是詹姆斯邦德，正如其中一位博客所说的那样 - 它比git更优雅，更高级，至少表面上看。此外，它的命令与subversion命令非常相似，因此svn转换的新用户可能比git更快地学习Mercurial。

Answer 3

我认为你的朋友不会注意到这三个VCS中的任何一个都有很大不同。如果它只是用作具有少量分支的简单备份（无论如何可能没有冲突），那么它们选择哪种工具并不重要。这三个人都可以完成简单的任务，而无需用户知道任何特殊的东西。

特别是如果人们对版本控制完全不熟悉，那么就没有理由选择一种工具而不是另一种工具。虽然他们都使用略有不同的概念（Git可能是最特别的概念），但如果没有其他工具的经验，新用户几乎不会注意到这一点。

您列出的专业人士的分布情况缺点（这不是真正的btw）告诉我你对Mercurial的经验比Git更多或更深。因此我建议使用Mercurial，因为在你的朋友需要帮助的情况下，他们可以问你，你将能够根据自己的经验给他们一个很好的答案。

我认为这比互联网上的整体用户群或某些帮助页面更重要（顺便说一下。大量的git问题也可能意味着git对许多人来说更加混乱 - 这可能是某种程度上的真实情况）

为没有经验的用户决定工具的另一个因素，特别是那些可能在他们的生活中真的不需要它的人，可能是一些简单的图形用户界面的可用性。甚至可能与他们的TeX编辑器进行良好的集成，这将使他们选择一种工具而不是另一种工具。

Answer 4

推荐你认识最好的人。如果你要向熟人推荐一个，你应该愿意先回答他们的问题。 Mercurial，Git和Bazaar都很棒，而且几乎没有任何优势。如果他们发现缺陷，那么他们可以尝试其中一个，但老实说，为了开始，“Machts nichts！”

Answer 5

在两种情况下，我将从头开始传递我对Git和Mercurial的经验。

我决定从ClearCase（UCM移动我的团队（包括我自己在内的5位顶尖和纪律严明的开发人员），但他们几年都使用了基础ClearCase和UCM）。看了Mercurial，Git和Bazaar的所有3个，我选择了Mercurial（受PEP 374影响很大）。

在一周之内，我有足够的信心将Mercurial引入团队流程，人们开始转向使用它。最大的困难是确保我能够继续将更改推送到ClearCase上游。整个团队迅速采用了它，我们注意到我们的工作方式立即发生了变化。

我们使用非常分支的开发（每个任务命名分支） - 基本上继承了ClearCase的工作方式，但我们发现这是团队工作的好方法（注意 - 一个很多的Hg用户不喜欢这种分支策略）。开发人员可以处理任务并将其发送给某人进行审核。以前审阅者会通过并做笔记等，并将其发送回原始开发人员，Mercurial发现我们只需切换分支，审阅，然后让作者在评论者的环境中一起进行更改（结对编程）并将它们提交给同一个命名分支。

总而言之，整个团队加快速度的总时间（以我为导师从头开始）大约需要2周。

我使用Git的经历是最近的 - 我大约2个月前才开始使用它（因此已经有了相当多的Mercurial经验）。但是，我确实大约2个月前开始使用它，而我现在才开始觉得它很舒服。使Git感到不舒服的最大问题是，Git假设您将编辑历史记录并使其简单。我必须定期阅读git帮助/手册的部分内容，以确定我正在做“正确”的事情。我发现本地分支+远程跟踪分支系统非常陌生，而Mercurial中的分支非常简单（要找出你与其他仓库相比的位置，你只需要它）。

我正在与之合作的团队也有同感。 Git决定参加VCS，但现在我被要求在目前的工作阶段结束时将我们改为Mercurial。

Answer 6

我喜欢Mercurial。我有偏见。我也喜欢Perforce，但它不是那么开放。

Answer 7

StackOverflow上的标签应该可以很好地指示其背后的社区支持。目前，问题的数量是：

• Git ：5,789
• Mercurial ：1,845
• Bazaar ：188

以饼图形式展示：

现在，这不应被视为Git比Mercurial更难使用的标志，而是有很多人提出有关它的问题并获得有关的帮助。这意味着，如果您的新手被卡住，他们在git代码中获得帮助的可能性大于Bazaar代码中的帮助。

我在my answer to "Should a developer always use version control"中介绍了一些基本的git提交。

此外，还有GitHub这是一个非常棒的git存储库托管网站，就像一个好的Red，随着年龄的增长变得异常好。例如，他们的新文件浏览器让我感到厌倦。

总而言之，我绝对认为新手应该使用Git，因为有更多人在那里使用它，GitHub使用它，如果他们碰巧使用Ruby编程语言，那么它实际上是事实上的标准。

Answer 8

GIT中。

我碰巧喜欢Mercurial，这是我对DVCS的介绍，但现实是Git正在成为行业标准。当我与朋友讨论他们在工作中使用的内容时，每个人都在使用Git进行新项目，将现有项目迁移到Git，或者希望他们能够在工作中使用Git，如果他们将其用于个人项目但是可以＆ ＃39;让人们切换工作。从来没有人谈论Mercurial或Bazaar。我曾经是唯一一个跟Mercurial谈过的人，但是当我明白Git是专业开发人员在可预见的未来将会使用的时候，我就会加入Git的行列。人们仍然在谈论SVN，偶尔会谈论CVS，但那是因为他们的项目是在几年前开始的，他们还没有迁移，没有人谈到将它们用于新开发。

如果你们在完成论文后计划以开发人员的身份获得工作，那么了解人们实际使用的工具符合你的最佳利益。

这不是你的选择之一，但我只是想补充一点，Perforce很糟糕，应该永远不会被开发出来，并且是你能想象到的最烦人和最具侵略性的VCS。