请原谅,这可能以前曾被问过,但是我无法通过所有复杂的选项找到想要做的简单事情。
在我的默认分支上,我进行初级开发。不久前,我创建了一个“ beta”分支(现在为160版),以使beta测试人员可以在稳定的版本上工作,而主要开发仍在继续。 (现在的版本为200)
现在是时候更新beta分支,使其等于现在的默认分支的内容了。没有合并,没有花哨的讨论,只是将beta分支中的内容完全替换为默认分支顶端的内容。这是嫁接的工作吗?
我看到了很多关于将“提交”从一个分支移动到另一个分支的讨论,但这是否意味着与使用最新提交的整个内容移动一样?
一个命令行示例将是最有用的。
答案 0 :(得分:1)
我发布了一个指向可能重复项(Mercurial: make one branch identical to another)的关闭请求链接,但我想我应该添加以下内容...
嫁接绝对不是您想要的。嫁接意味着将一个变更集或一定数量的变更集从一个分支或分支内的线程 1 复制到另一个。
可以使用内置于合并工具中的hg merge
使用:other
将不同分支的技巧提交(或实际上是任何非技巧提交)复制到您自己的分支。 2 与其他答案的关闭并重新打开方法不同,它记录了实际的合并。没有特别的理由偏爱一种方法。
1 尚不清楚该怎么称呼。 编辑: Mercurial文档将这些匿名分支称为。当您以更类似于Git的方式使用Mercurial时,会得到它们,它们使用书签来跟踪单个命名分支中的多个头部:
c4--c5 <-- bookmark1
/
default: c1--c2--c3 <-- bookmark2
\
c6--c7--c8 <-- bookmark3
在Git中,这些书签是分支:根本没有永久分支,而您得到的只是书签。
(附带说明:尚不清楚Mercurial是否将c3
视为匿名分支。Commit c3
不是头,并且即使hg heads
也没有列出,书签标识它。如果更新到书签,然后创建一个 new 提交,并拖动书签以跟踪其进度,匿名分支将在以后有效地萌芽。)
2 这等同于Git缺少的-s theirs
合并策略。与:local
(相当于Git的-s ours
策略)进行比较,并将tis与:merge-local
或:merge-other
进行对比,后者将双方的更改合并,但希望我们双方能够自动解决合并冲突。