在 Git 中,我可以这样做:
1. Start working on new feature: $ git co -b newfeature-123 # (a local feature development branch) do a few commits (M, N, O) master A---B---C \ newfeature-123 M---N---O 2. Pull new changes from upstream master: $ git pull (master updated with ff-commits) master A---B---C---D---E---F \ newfeature-123 M---N---O 3. Rebase off master so that my new feature can be developed against the latest upstream changes: (from newfeature-123) $ git rebase master master A---B---C---D---E---F \ newfeature-123 M---N---O
我想知道如何在 Mercurial 中做同样的事情,我已经在网上搜索了答案,但我能找到的最好的是:git rebase - can hg do that
该链接提供了 2 个示例: 1. 我承认这一点:(将示例中的修订替换为我自己示例中的修订)
hg up -C F hg branch -f newfeature-123 hg transplant -a -b newfeature-123
还不错,除了它将 pre-rebase MNO 作为未合并的头部留下并创建 3 个新提交 M’,N’,O’ 代表它们从更新的主线分支。
基本上问题是我最终得到了这个:
master A---B---C---D---E---F \ \ newfeature-123 \ M'---N'---O' \ newfeature-123 M---N---O
这不好,因为它留下了应该删除的本地不需要的提交。
hg qimport -r M:O hg qpop -a hg up F hg branch newfeature-123 hg qpush -a hg qdel -r qbase:qtip
这确实会产生所需的图表:
主 A---B---C---D---E---F \ newfeature-123
但是这些命令(全部 6 个!)似乎比
$ git rebase master
我想知道这是否是 Hg 中唯一的等价物,或者是否有其他可用的方法,比如 Git。
有您正在寻找的答案,即 Rebase Extension。然而,值得花一两秒钟时间思考为什么在mercurial 中默认情况下既不启用 mq 也不启用 rebase:因为 mercurial 完全是关于不可磨灭的变更集。当我以您描述的方式工作时,几乎每天都有,这是我采用的模式:
1. Start working on a new feature: $ hg clone mainline-repo newfeature-123 do a few commits (M, N, O) master A---B---C \ newfeature-123 M---N---O 2. Pull new changes from upstream mainline: $ hg pull master A---B---C---D---E---F \ newfeature-123 M---N---O 3. merge master into my clone so that my new feature can be developed against the latest upstream changes: (from newfeature-123) $ hg merge F master A---B---C---D---E---F \ \ newfeature-123 M---N---O---P
这就是真正需要的。我最终得到了一个 newfeature-123 克隆,当我对它感到满意时,我可以轻松地推回主线。然而,最重要的是,我 从未改变历史 。有人可以查看我的 cset,看看它们最初是针对什么进行编码的,以及我在整个工作过程中对主线变化的反应。不是每个人都认为这是有价值的,但我坚信源代码控制的工作不是向我们展示我们希望发生的事情,而是向我们展示实际发生的事情——每一个死胡同和每一个重构都应该留下不可磨灭的痕迹,并重新定位和其他历史编辑技术隐藏了这一点。