你为什么用Git代替Mercurial?(反之亦然。)[关闭]

(A)前3名 真实的 我选择使用Git而不是Mercurial的原因:

1. 历史随机性/惯性
2. 历史随机性/惯性
3. 历史随机性/惯性

(B)鉴于上述情况,我喜欢Git胜过Mercurial的前三点:

1. 索引
2. 轻质树枝
3. 正常标记(标记不是标记的提交之后的提交)

(C)Mercurial在Git上有三件事:

1. 更好的 本地的 文件(强调 本地的 ,因为 ProGit book 是非常出色的,任何对Git或Git模型过于复杂或混乱有任何抱怨的人都应该直接去那里)
2. 顺序提交编号(仅限于本地存储库范围,但我认为这有时可能比在处理时剪切和粘贴SHA-1更方便?)
3. 更好的标志/名称?

我想这一切(大部分?)(B)中的项要么是由于(a)我被用于Git模型的结果,要么可以通过插件在Mercurial中“修复”。但事实仍然是Git的工作方式是我希望它开箱即用的,而且我可以不使用任何(C)项(考虑到C(1)由于优秀的ProGit书籍而成为非问题)。所以,我继续使用Git而不是Mercurial。

我同时使用了Mercurial和git,我非常喜欢hg而不是git;它只是 感觉 更好。史蒂夫洛什在他的博客中 The Real Difference Between Mercurial and Git 总结了我对此的大部分感受。以下是我完全同意的几句话:

我认为还有一个非常非常重要的区别: 系统 感觉 使用起来很不一样。

我个人觉得摩科瑞的哲学更容易运用。当命令变得更模块化,而不是单一化时,我很容易把自己的头绕在命令上。

我个人不喜欢索引。我觉得git鼓励人们签入包含他们从未测试过(甚至构建过)的代码的变更集,因为索引是git工作流中非常重要的一部分。

我发现索引是一个很难处理的问题-如果我想要这样的东西(而且功能也更强大),我将使用mq。同时-为什么我要被迫有不同类型的 add 等等。?为什么我要被迫使用 git commit -a (并且 git status -在哪 git st ? -显示奇怪的信息?

非常严肃地说,我个人可以把git的成功和广泛接受归功于GitHub。史蒂夫也很喜欢这个。人们可能是如何经历这一切的,并“屈服于”来自git用户的压力的?

我不喜欢使用git本身(尽管它比SVN或CVS好得多),但GitHub是一个非常棒的网站,我曾考虑过只使用它。

我将继续只在需要的时候使用git/GitHib——当我想对上面的东西做一个补丁时。我自己的项目将继续使用Mercurial。感觉好多了。

我使用mercurial的主要原因是:

1. 在我通常使用的更多开源存储库(即Bitbucket和Codeplex)中都支持它
2. 在窗户上开箱即用效果很好

否则,就风投业务本身而言,它们几乎是一样的。

(编辑:为了澄清——我不是说mercurial比mercurial好——我的理解是Git比mercurial在一般应用中更快,而且我实际上还没有使用Git那么多来评论。但这两个原因 是 为什么我使用mercurial而不是git)

没有汞和吉特是非常相似的。

我个人的看法是,这些分歧是高度夸大和激情的,经不起更严格的审查。

差别不大。

Git倾向于暴露模型而不是多变的。 Mercurial倾向于拥有比Git更小的命令子集,并反映了这一理念。

Mercurial有许多其他用途的扩展

其他的大部分工作可以通过使用Mercurial中强大的扩展模型来实现。它还具有易于扩展的优势,因为大多数Mercurial代码都是用Python编写的,您可以像运行本地Mercurial命令一样运行扩展。

一些链接

有关更多信息和详细信息,请参见以下讨论

• What are the pros and cons using git VS Mercurial with Xcode for iOS development in big teams?

下面提供了Git和Mercurial之间区别的简洁视图

• https://www.mercurial-scm.org/wiki/GitConcepts

为什么,比起Git,我更喜欢Mercurial。

[又是个人充满激情和偏见的观点]

这些命令实际上是Git中可用命令的一个子集,似乎已经足够了。再怎么说,那感觉就像是过度放纵。

我使用Mercurial是因为code.google.com支持它。我也使用它,因为它是用Python编写的(主要是)并且易于扩展。它也很容易安装在许多操作系统上。与我共事的一些人害怕命令行,喜欢有能力使用GUI工具,所以我把他们指给乌龟。

两者各有利弊。用你觉得舒服的。

奖励链接:

gitvsmercurial.com

gitvsmercurial.com via Wayback Machine

死后

自从写了这个答案,我已经成为一个主要的git用户,主要是因为 GitHub . 我也开始在工作中使用Subversion。我宁愿不使用Subversion。

其中6个,另1/2打。我从反复无常转到了Git,因为我的团队中的另一个人更喜欢它。不过,我认为他更喜欢它只是因为他先学会了。

我更喜欢git,因为:

• 似乎 更快 对我来说。
• 更内置 工具 .
• 更高的帮助、问题和 讨论 (即使在这个网站上)。
• github 非常有用。
• 现在有很多使用Git的活跃/前沿开发,特别是在 Javascript和Ruby社区 .

几年前我在复习DVCS时:

• bzr与Python2.4绑定,不会在2.5上安装/运行。

• Windows上对git的支持充其量也只是粗略的。

离开了hg。我对hg很满意。hg社区似乎关注用户体验,这让我这个用户感到高兴。git-UX似乎花了很长时间才开始走向“易用性”,这并不让我倾向于看好它。

有一些事情我认为HG需要:灵活的元数据和大文件轻松脱颖而出。但是,这些方面不会干扰我的常规用例,如果我真的需要它,我可以编写/修改扩展而不会有很大的痛苦。

你可以用这两种方法达到同样的效果,但这并不意味着差异是肤浅的。

使用Git daily已经有几年了,Mercurial daily已经有一个月了,我发现两者有着截然不同的感觉。

到目前为止,我的经验是,当在一个集中的工作流中进行协作时,Mercurial使保留私有开发分支更加困难,而不保留存储库的多个克隆。有了Git,你必须明确自己的共享内容。

因此,对于Git来说,进行随意的黑客攻击感觉没什么大不了的;例如,如果是一个工作项目,也许你“不应该”做的事情。它降低了尝试新想法的心理障碍。

因为我喜欢在我自己的存储库副本上做任何我想做的事情,并且只与其他人分享我想让他们看到的(以及对他们有用的东西),所以我更喜欢Git,因为它似乎使这变得更容易。

另一件事:我第一次看到Mercurial的PythonAPI时非常兴奋(因为我是一个Python用户)。我以为我会有一个伟大的时间写扩展。然后我看到了 warnings 不能保证API保持兼容。

由于我懒惰(我认为这是一个高尚的特性,在某个时候也曾是哈斯凯尔的玩偶),我很快就放弃了这个想法,并感到失望。

在那里的时候 是 一些可用性差异(我对Git的主要意见是默认情况下不启用color;Hg默认情况下缺少pager、color、colordiff的hack、purge,仅仅因为有一个扩展框架并不意味着您不应该将它们发布到任何地方并启用它们),我坚持使用Git的一个重要原因是,它在社区中有更多对我重要的思想共享。尽管Hg在Mozilla项目中处于领先地位,Git已经成为arbales提到的社区(尤其是javascript和web基础设施)、Gnome、内核以及我发现有用的随机项目的长尾的标准。

网络效应并不意味着营销决定一切。Git的工具集是生成性的,效率非常高(它用于很多备份、存档和数据完整性方面);Hg的扩展也必须是生成性的,但更多的是在ui增强的层面上。Git启动了一些有用的标准,比如快速导入。我认为这就是为什么它吸引了更多的系统构建者类型,他们是改进git、完成git以及将他们的东西放入git的好种子。

历史上的意外。我 起动 在Mercurial发布前几天使用Git。我 保持 使用Git是因为我懒得重新学习。

IOW:当我开始使用Git时,水星不存在,所以我实际上从来没有在两者之间做出有意识的决定。

不过,我喜欢以下几点:

• 我关心的每个项目都使用Git,少数不使用Git的项目提供了一个双向网关
• GitHub , Codaset , Assembla , Codebase , Gitorious , Repo.Or.Cz (移动分支FTW), Unfuddle , ProjectLocker , SourceForge , TuxFamily
• 也就是集结地。指数
• 很容易接近低层的“管道”(我做了一些 疯狂的 我不得不用Mercurial为其编写一个Python扩展。在Git中,我只是调用命令)例如,我合并了两个没有共同历史的存储库,类似于 Coolest Merge Ever .