`hg pull --rebase`类似于'svn update`吗？

Question

这个问题假定团队成员有一个"有福的"中央存储库

1. 克隆自
2. 当他们有他们希望其他团队成员看到的贡献时,推动他们
3. 当他们想要看到其他人的贡献时拉出来.
4. 等等

如果是这样,我会假设hg update不是类似于svn update(为什么会有两个命令完全相同？).从我可以收集到的,hg update更像是svn revert.那是对的吗？

更新:

我对rebase的理解主要基于本页的"常见案例"部分:https:
//www.mercurial-scm.org/wiki/RebaseProject

Answer 1

正如其他人所指出的,差不多但并不完全.为了减少相似性svn update(并增加对一般DVCS的遵守,特别是Mercurial,最佳实践[1]):

1. hg pull -u(或者hg pull之后hg update)您的更改未提交,并且自上次提取以来没有提交更改.这是尽可能接近svn update,但DVCS的做法非常糟糕.DVCS的一个细节是你可以在尝试将它们与其他人合并之前提交你的更改,从而有一个备份版本来回滚并重试失败的合并,这种做法就是这样.不要这样做.

2. hg pull --rebase在提交更改后.这会拉动上游更改,在其上重新应用更改,并允许您将更改作为线性历史记录推回.最终结果看起来与Subversion修订历史非常相似,但您可以在合并之前获得DVCS提交的好处.我不知道这种操作模式的安全性如何在Mercurial和Git之间进行比较; 在Git中,您的更改的pre-rebase版本仍然存在,直到您执行git gc,但Mercurial没有明确的gc安全网.

3. hg pull然后hg merge将您的更改提交到本地副本.svn update尽管下面的脚注1,这是传统的Mercurial实践,用于执行功能模拟.这会产生非线性版本历史记录,但会跟踪和检查所有更改.

也就是说,以自己的方式思考Mercurial(以及其他DVCS)并且不尝试从Subversion/CVS风格的思维转换,有很多智慧.

1. 如果你不是重写 - 历史 - 保持线性的思想学派.如果你是,那么rebase可能更好update.Mercurial社区倾向于支持update.

Answer 2

不完全是.

hg pull从其他存储库获取修订并将它们添加到存储库克隆中的本地可用修订版本,但不更新您的工作副本 - 仅更新您的存储库(对于像hg/git/etc这样的DCVS不同于工作副本).

hg update 将您的实际工作副本更新到本地存储库中的最新版本.

这与Subversion不同,因为在svn中,没有"本地存储库"这样的东西 - 唯一的存储库是服务器上的存储库; 你只在本地有一份工作副本.因此,为什么update只有一个命令,而不是Mercurial的pull然后update.

相当于svn updateMercurial hg pull --update,相当于做hg pull,然后hg update一个接一个.

具有"中央"仓库的DCVS的端到端工作流程如下所示:

1. A做hg commit了一些改变.
2. A hg push将它们推向中央存储库.
3. B确实hg pull将它们从中央存储库拉到自己的克隆中.
4. B确实hg update更新了他们的工作副本以反映拉入其克隆的更改.

在没有中央存储库的系统中,它看起来像这样:

1. A做hg commit了一些改变.
2. 已经克隆了A的回购的B,想要这些改变,因此hg pull直接来自A的回购.
3. B用于hg update将其工作副本更新为更改.

另外,相当于svn revert是hg revert.:)