相关疑难解决方法(0)

在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 …

Mercurial 2.0 的发布公告提到了一个新的移植命令,乍一看看起来与移植扩展类似.这两者有什么区别？用移植物采摘樱桃是否可以解决移植中存在的任何问题,如果是这样的话,这些是什么？

我知道Rebase是一个(捆绑式)扩展,而Graft是一个核心功能(取代了Transplant(捆绑)扩展).

graft 记录为:

将其他分支的更改复制到当前分支

此命令使用Mercurial的合并逻辑从其他分支复制单个更改,而不在历史记录图中合并分支.这有时被称为"backporting"或"cherry-picking".

rebase 记录为:

Rebase允许在Mercurial的历史中移动提交(使用一系列内部合并).这有很多用途:

• 在分支之间移动变更集
• "线性化"历史
• 重新排序变更集
• 将多个更改折叠为一个更改集

两者似乎都使用合并来移动或复制分支之间的变更集.

嫁接副本.Rebase移动.但rebase --keep副本.

因此,似乎我可以实现以任何方式复制变更集的目标.我使用哪一个是否重要？我什么时候应该更喜欢一个？

例如,只有在复制到不同的命名分支时才能使用移植？或者只有在只有一个变更集时？

编辑:可能是rebase是一个潜在的不安全的移植超集,但是只能draft在开发期间用于编辑本地历史记录的变更集,而移植是一个安全的rebase子集,可以public在维护后用于变换集以进行反向移植？