ico*_*ast 26 git mercurial dvcs
我目前使用Git,我对它很满意,但我想更多地了解Mercurial.它比Git有什么优势吗？Git比Mercurial有什么优势？
我意识到已经对这两者进行了详细的比较,但这不是我要求的.我不想要冷静的信息,而是慷慨激昂(但礼貌!!!)的理由,为什么你认为一个更好/更容易/更快/更聪明/更强大等等.
Chr*_*gan 27
我使用了Mercurial和git,我非常喜欢hg和git; 它只是感觉更好.史蒂夫·洛什在他的博客文章"Mercurial和Git之间的真正差异"总结了我对此的大部分看法.以下是我全心全意同意的一些引言:
我认为仍然存在一个非常非常重要的区别:系统使用时感觉非常不同.
我个人觉得Mercurial的理念更容易使用.当它们更模块化,更少整体时,我很容易绕过命令.
我个人不喜欢索引.我觉得git鼓励人们检查包含他们从未测试(甚至构建)的代码的变更集,因为索引是git工作流程中非常重要的一部分.
我发现索引很难用 - 如果我想要这样的东西(也更强大)我将使用mq.同时 - 我为什么要被迫拥有不同类型的adds等？我为什么要被迫使用git commit -a(并且有git status- 在哪里git st？ - 显示奇怪的信息)？
非常认真地说,我个人可以将git的成功和广泛接受归功于GitHub.史蒂夫也抓住了这个.人们怎么可能通过这个,并"屈服于"来自git用户的压力？
我不喜欢使用git本身(尽管它比SVN或CVS好得多),但GitHub是一个非常棒的网站,我考虑过转换它只是为了使用它.
我将继续只在需要时使用git/GitHib - 当我想要修补那里的东西时.我自己的项目将继续使用Mercurial.感觉更好.
Jee*_*eet 14
(A)我使用Git而不是Mercurial的三大真正原因:
(B)考虑到上述情况,我最喜欢Git over Mercurial的三件事:
(C)Mercurial对Git的三件事:
我认为(B)中的所有(大多数？)项目都是由于(A)因为习惯于Git模型而导致的,或者可以通过插件在Mercurial中"修复".但事实仍然是Git以我想要的方式开箱即用,并且我可以在没有任何(C)项目的情况下生活[假设由于优秀的ProGit书而使C(1)成为非问题] .而且,我继续使用Git而不是Mercurial.
Bil*_*eal 12
我使用mercurial的主要原因是:
否则,就VCS操作本身而言,它们几乎是相同的.
(编辑:为了澄清 - 我不是说mercurial是优越的 - 对我的理解Git比一般使用中的mercur更快,而且我实际上并没有使用git那么多来评论.但这两个原因是为什么我使用mercurial而不是git)
没有Mercurial和Git非常相似.
我个人认为,这些差异是高度夸大和激情的,不会受到更严格的审查.
差异很小.
Git倾向于比Mercurial更多地暴露模型.Mercurial倾向于拥有比Git更小的命令子集,并且反映了这种理念.
Mercurial具有大多数其他用途的扩展
通过在Mercurial中使用强大的扩展模型,可以实现大多数其他功能.它还具有易于扩展的优点,因为大多数Mercurial代码都是用Python编写的,您可以运行Extensions,就像它们是本机Mercurial命令一样.
一些链接
有关其他信息和详细信息,请参阅以下讨论
以下提供了Git和Mercurial之间差异的简洁视图
为什么,我更喜欢Mercurial而不是Git.
[再次个人激情和偏见]
这些命令确实是Git中可用的部分,看起来非常充分.更重要的是,感觉过度放纵.
我使用Mercurial是因为code.google.com支持它.我也使用它,因为它(主要)是用Python编写的,并且很容易扩展.它也可以轻松安装在许多操作系统上.我工作的一些人害怕命令行,并且有能力使用GUI工具,所以我将它们指向TortoiseHg.
两者都有其优点和缺点.使用你更舒服的任何一个.
奖励链接:
gitvsmercurial.com通过Wayback Machine
自写这个答案以来,我主要成为git用户,主要是因为GitHub.我也开始在工作中使用Subversion.我宁愿不使用Subversion.
您可以使用两者实现相同的目标，但这并不意味着差异是表面的。
我已经每天使用 Git 几年了，现在每天使用 Mercurial 大约一个月了，我发现两者有明显不同的感觉。
到目前为止，我的经验是，当在集中式工作流程中进行协作时，Mercurial 使得在不保留存储库的多个克隆的情况下保留私有开发分支变得更加困难。使用 Git，您必须明确说明您共享的内容。
因此，有了 Git，随意的黑客攻击就不再是一件大事了；例如，如果这是一个工作项目，也许你“不应该”做的事情。它降低了尝试新想法的心理障碍。
因为我喜欢能够在我自己的存储库副本上做任何我想做的事情，并且只与其他人分享我希望他们看到的内容（以及对他们有用的内容），所以我更喜欢 Git，因为它似乎使这变得更容易。
另一件事：第一次看到 Mercurial 的 Python API 时我确实感到非常兴奋（因为我是 Python 用户）。我以为我会在编写扩展方面度过一段愉快的时光。然后我看到了警告，指出该 API 不保证保持兼容。
由于我很懒（我认为这是一个崇高的特征，在某些时候也曾是 Haskell 的涉猎者），所以我很快就放弃了这个想法，而且很失望。
我更喜欢git,因为:
几年前我在审查DVCS时:
bzr与Python 2.4绑定,不会安装/运行2.5开箱即用.
Windows上的git支持充其量是粗略的.
那让hg.我对hg非常满意.hg社区似乎关注用户体验,这让我,一个用户,开心.混帐UX似乎需要很长的时间来启动对"易用性",这不我倾向于积极考虑在其移动.
我认为hg需要具备一些东西:灵活的元数据和大文件易用性.然而,这些方面不符合我经常使用干扰的情况下,如果我真的需要它,我可以写/修改扩展名不显著悲痛.
| 归档时间： |
|
| 查看次数： |
5320 次 |
| 最近记录： |