如果我有一个好的修订:3200。然后我想测试一些东西,因为它有 10 行更改,我需要删除几行,即使我仍在测试我先提交,然后再进行一些更改,再次提交,比方说,我做了 6 次提交。
现在我想搁置这个,但我不想失去所有的测试和编写的代码,所以我想
$ hg up -r 3200
哪个是我想要的好的、稳定的版本,现在我可以提交和推送作为提示吗? (如果可能的话,我想避免退出
hg backout
,因为它看起来有点糟糕,而且我不想回滚,因为回滚有副作用“如果有人在这段时间从我身边撤走,变化可以以某种方式回到回购”)
在 Mercurial 中可以通过多种方式将事情搁置。最简单的方法就是不要将它推到任何地方。在你回到历史之后
$ hg update 3200
你可以使用
$ hg push -r .
仅推送到修订版 3200。
.
很重要 — 它表示工作副本父修订版,在本例中为 3200。修订版 3200 不会在您的本地存储库中“提示”,因为您仍有修订版 3201–3206 , 并且编号最高的版本是 always 我们称之为“提示”。换句话说,历史看起来像这样:
[3199] -- [3200] -- [3201] ... [3205] -- [3206]
^ ^
"." "tip"
我在其中标记了当前工作副本的父版本和最新版本。
当您开始基于修订版 3200 工作时,图形将变为
[3199] -- [3200] -- [3201] ... [3205] -- [3206]
\
\-------------------------------- [3207]
^
".", "tip"
请尽量不要过分强调“提示”。它一直在变化,通常不是很有趣。如果您跳回 3206 并进行提交,则 tip 将表示您的存储库中新创建的修订版 3208。在另一个存储库中,tip 可以是其他东西,这取决于从你那里提取的内容以及 when 它被提取。
如果你经常需要做
hg push -r .
,那么我建议你为它创建一个alias。这样的别名会更温和,因此可以称为“轻推”:
[alias]
nudge = push -r .
在你的工具箱里,你可以随时做
$ hg nudge
将您刚刚创建的变更集发送到服务器,而不必担心发送您可能搁置的任何其他分支。
最后,记得可以用
$ hg update 3206
$ hg commit --close-branch -m "Abandoning this line of development"
将 3206 变更集标记为“已关闭”。这意味着它不会出现在
hg heads
中,并且当您运行hg merge
时它不会被考虑合并。如果你将它推送到服务器,你will需要使用hg push --force
,但是没关系,因为你没有创建多个开放的头,你只需添加另一个封闭的头。
多个 open heads 的问题实际上是一个新的
hg clone
可能会更新到其中一个,这会让人感到困惑——人们不知道从哪里开始工作。在最新版本的 Mercurial 中,hg clone
不会更新为封闭的头部,因此您可以避免这个问题。
您可以通过简单地让孩子基于它提交来重新打开一个封闭的头。这意味着您可以暂时关闭一条开发线而不会产生不良影响,除了图表中的一条注释表明该分支在某个时候关闭了。
从问题和随附的评论来看,听起来您希望所有新更改都基于 3200,将之前基于 3200 的工作作为一个单独的分支。这很容易做到:
hg up 3200
# work work
hg ci -m "new work based on 3200"
但据我所知,没有任何方法可以将 3200 标记为小费。一旦您提交了基于 3200 的内容,新的变更集将成为提示,因此您可以进行一些良性更改并提交以创建新提示,但这有点笨拙。如果您担心其他合作者不知道使用 3200 作为他们工作的基础,因为 mercurial 不会将其标记为提示,则另一种选择是给它一个标签并告诉团队成员确保并更新他们的工作副本在开始他们的工作之前到那个标签。
krupans的回答当然是正确的,他已经提到了现在有两个头的问题。但我想强调的是,你将有同一个分支的两个负责人,其他人可能很难理解发生了什么,以及使用哪个负责人。
出于这个原因,将您的测试代码放入一个新分支可能是有益的,为此您将不得不重写历史。您可以使用 MQ 扩展执行此操作(假设 3201 是 rev 3200 的子修订版,而 3206 是您的最后一个测试提交:
hg qimport -r 3201:3206
hg qpop -a
hg branch branchname
hg qpush -a
hg qfinish -r 3201:3206
在你的仓库的克隆上试试这个!
只有在您还没有将这些更改推送到其他地方时才应该这样做。