Mercurial和Git有什么区别？

它们几乎相同.从我的角度来看最重要的区别(我的意思是,让我选择一个DVCS而不是另一个的原因)是两个程序如何管理分支.

要使用Mercurial启动新分支,只需将存储库克隆到另一个目录并开始开发.然后,你拉和合并.使用git,您必须明确地为要使用的新主题分支命名,然后使用相同的目录开始编码.

简而言之,Mercurial中的每个分支都需要自己的目录; 在git中,您通常在单个目录中工作.在Mercurial中切换分支意味着更改目录; 在git中,这意味着要求git使用git checkout更改目录的内容.

我很诚实:我不知道是否可以对Mercurial做同样的事情,但由于我经常在网络项目上工作,因为我总是使用git这个目录看起来很舒服,因为我没有必要 - 配置Apache并重新启动它,每次分支时我都不会弄乱我的文件系统.

编辑:正如Deestan所说,Hg已命名分支,可以存储在单个存储库中,并允许开发人员在同一个工作副本中切换分支.无论如何,git分支与Mercurial命名分支并不完全相同:它们是永久性的,不会丢弃分支,就像在git中一样.这意味着如果您使用命名分支进行实验任务,即使您决定永不合并它,它也将存储在存储库中.这就是为什么Hg鼓励将克隆用于实验性的,短期运行的任务以及为长期运行的任务命名分支的原因,例如发布分支.

许多Hg用户优先克隆命名分支的原因是社交或文化比技术更多.例如,对于Hg的最新版本,甚至可以关闭命名分支并递归地从变更集中删除元数据.

另一方面,git邀请使用"命名分支",这些分支不是永久性的,并且不作为元数据存储在每个变更集上.

从我个人的角度来看,git的模型与命名分支的概念密切相关,并在分支和另一个分支的同一目录之间切换; hg可以对命名分支做同样的事情,但它鼓励使用克隆,我个人不太喜欢.

git和mercurial之间有一个巨大的区别; 表示每次提交的方式.git将提交表示为快照,而mercurial将它们表示为差异.

这在实践中意味着什么？好吧,git中的许多操作都比较快,例如切换到另一个提交,比较提交等.特别是如果这些提交很远的话.

AFAIK没有mercurial方法的优势.

没有.他们都做同样的事情,两者表现平平.你应该选择一个而不是另一个的唯一原因是,如果你帮助了一个已经使用过的项目..

选择一个的另一个可能原因是只支持系统之一的应用程序或服务.例如,我几乎选择学习git因为github ...

谷歌的比较(虽然有点旧,2008年完成)

http://code.google.com/p/support/wiki/DVCSAnalysis

如果我正确地理解它们(并且我远不是每个人的专家),他们从根本上都有不同的理念.我第一次使用mercurial 9个月.现在我用git 6.

hg是版本控制软件.它的主要目标是跟踪一个软件的版本.

git是一个基于时间的文件系统.它的目标是为文件系统添加另一个维度.大多数都有文件和文件夹,git增加了时间.它恰好工作得很棒,因为VCS是其设计的副产品.

在hg中,它总是试图维护整个项目的历史.默认情况下,我认为hg希望所有用户在推送和拉动时对所有对象进行所有更改.

在git中,只有一个对象池和这些跟踪文件(分支/头),它们确定哪些对象集代表特定状态下的文件树.当推或拉git时,只发送你正在推或拉的特定分支所需的对象,这是所有对象的一小部分.

就git而言,没有"1个项目".你可以在同一个仓库中拥有50个项目,git也不会关心.每个人都可以在同一个仓库中单独管理并且生活得很好.

Hg的分支概念是主要项目的分支或分支机构等.Git没有这样的概念.git中的一个分支只是树的状态,一切都是git中的一个分支.官方,最新或最新的分支在git中没有任何意义.

我不知道这是否有意义.如果我可以绘制图片,hg可能看起来像每个提交是一个o

             o---o---o
            /        
o---o---o---o---o---o---o---o
         \         /
          o---o---o

一棵树,一根根,树枝从树上掉下来.虽然git可以做到这一点,但人们通常会以不强制执行的方式使用它.git图片,如果有这样的东西,很容易看起来像这样

o---o---o---o---o

o---o---o---o
         \
          o---o

o---o---o---o

事实上,在某些方面,在git中显示分支甚至没有意义.

有一件事让讨论非常困惑,git和mercurial都有一个叫做"分支"的东西,但它们并不是一回事.当不同的回购之间存在冲突时,mercurial中会出现一个分支.git中的分支显然类似于hg中的克隆.但是克隆虽然可能会产生类似的行为,但绝对不一样.考虑一下我使用相当大的铬回购在git vs hg中尝试这些.

$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'

real   0m1.759s
user   0m1.596s
sys    0m0.144s

而现在使用克隆的hg

$ time hg clone project/ some-clone/

updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real   0m58.196s
user   0m19.901s
sys    0m8.957

这两个都是热门运行.即,我跑了两次,这是第二次.hg clone实际上与git-new-workdir相同.这两个都是一个全新的工作目录,几乎就像你打字一样cp -r project project-clone.这与在git中创建新分支不同.它的重量要大得多.如果在hg中存在真正相当于git的分支,我不知道它是什么.

我在某种程度上理解hg和git 可能会做类似的事情.如果是这样,那么他们引导您的工作流程仍然存在巨大差异.在git中,典型的工作流程是为每个功能创建一个分支.

git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support

那只是创建了3个分支,每个分支都基于一个名为master的分支.(我确信在git中有一些方法可以使每个1行而不是2行)

现在我要做的就是上一个

git checkout fix-game-save-bug

并开始工作.承诺等等.甚至在像chrome这样大的项目中,在分支之间进行切换几乎是即时的.我实际上不知道如何在hg中这样做.这不是我读过的任何教程的一部分.

另一个很大的区别.Git的舞台.

Git有这个阶段的想法.您可以将其视为隐藏文件夹.当您提交时,您只提交舞台上的内容,而不是工作树中的更改.这可能听起来很奇怪.如果要提交工作树中的所有更改,则git commit -a需要将所有已修改的文件添加到舞台中,然后提交它们.

那个舞台有什么意义呢？您可以轻松地分离您的提交.想象一下,您编辑了joypad.cpp和gamesave.cpp,并且您希望单独提交它们

git add joypad.cpp  // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp  // copies to stage
git commit -m "fixed game save bug"

Git甚至有命令来决定你想要复制到舞台的同一文件中的哪些特定行,这样你也可以单独拆分这些提交.你为什么想这么做？因为作为单独的提交,其他人只能提取他们想要的提交,或者如果有问题,他们只能恢复有问题的提交.

在versioncontrolblog上有一个动态比较图表,您可以在其中比较几个不同的版本控制系统.

这是git,hg和bzr之间的比较表.

在处理分支(特别是短期分支)方面存在很大的差异.

它是在解释本文(BranchingExplained) ,其与比较GIT中水银.

您的项目中是否有基于Windows的协作者？

因为如果有的话,Git-for-Windows GUI看起来很笨拙,困难,不友好.

相比之下,Mercurial-on-Windows是一个明智的选择.

在bitbucket.org的mercurial和github的git之间要注意的一点是,mercurial可以拥有你想要的尽可能多的私有存储库,但github你必须升级到付费帐户.所以,这就是我选择使用mercurial的bitbucket的原因.

去年的某个时候,我为自己的用途评估了git和hg,并决定使用hg.我觉得它看起来像一个更清洁的解决方案,并且当时在更多平台上运行得更好.不过,这主要是一个折腾.

最近,由于git-svn和作为Subversion客户端的能力,我开始使用git.这让我赢了,我现在完全转向git了.我认为它有一个稍高的学习曲线(特别是如果你需要围绕内部),但它确实是一个伟大的系统.我打算读一下John现在发布的两篇比较文章.