命名以前未命名的分支

看来命名以前未命名的分支并不真正解决问题。它创造了一个我无法找到解决方案的令人讨厌的多头问题。命名以前未命名的分支

这里是工作流程...

用户A开始于功能，他们期望小型工作，所以他们刚开始工作（关default分支）。这个变化是一个大项目，需要多个贡献者。因此，UserA问题... hg branch "Feature1"并继续工作，需要本地提交。

UserA然后从中央回购拉下变化，所以他可以推动。

在这一点上，为什么hg heads返回头？它对default显示2，对Feature1显示1。 default的第一个头是分支上其他用户的最新更改（无关）。第二个default头是hg branch "Feature1"提交之前的提交。

中央存储库的规则已执行，因此每个分支只允许一个头允许，因此强制推送不是一种选择。回购不需要default分支上的多个头。

UserA应该能够推送这些更改，以便其他用户可以看到Feature1分支并提供帮助。我似乎无法找到一种方法来“纠正”这一点。我认为在它是一个命名分支之前，我不能重写该功能的初始提交分支。

我知道命名分支在技术上是默认分支之前的初始更改，但这是否意味着它们将会是分支，直到Feature1分支被合并？

来源

2010-06-03 Jab

我已经找到了一个解决方案，无需重新克隆和合并更改。我更喜欢这种方法主要用于历史目的，因为我认为它对于该功能发生的有用信息（又称它开始很小，被认为是较大等）

在我的例子，用户A应该更新不需要的脑袋上default并关闭默认的一个分支，因为它是不必要的。如预期的那样，这将为default和Feature1留下两个头。

hg update -r X // X is the rev of the unwanted head. 
hg commit --close-branch -m "Moved to Named Branch Feature1, cleaning up initial work"

然后更新到Feature1分支，按下并继续工作。

除了UserA决定将Feature1推送给其他人以帮助其他人以及default尚未被其他人推进之外，其他工作流几乎相同。本地回购只有2个头，用户可以推送，但UserA不希望只是推，因为default的提示现在将变成真正“属于”Feature1的变更集。

用户A应该更新的defaul吨最新的，不必要的变更。然后在用户A开始工作之前将default恢复为修订版本。

hg update default 
hg revert -r Y // Y is the changeset before UserA started working on the feature 
hg commit -m "Reverting changes that now exist in Feature1 branch"

然后更新到Feature1分支，按下并继续工作。

来源

2010-06-04 15:08:08 Jab

当我写我的回答，我从你的问题了解你的主要关注点是在本地存储库是在'default'分支的变化“搬”到了'feature'分支。由于情况并非如此，合并这两个“默认”头肯定是一条路。 – 2010-06-04 17:04:45

你在本地回购的default分支上看到两个头的原因是，在最近的共同祖先之后，中央回购中的变更集与本地回购中的变更集没有任何共同之处。

解决你的问题：

创建你想要的（如果你使用最新的共同祖先它可能会更容易）的修订版中央回购的一个新的本地克隆。
```
hg clone -r common_ancestor central local2 
```
导出第一个本地回购的更改。注意first_local_change之后的冒号以获得该回购中的所有更改。
```
cd local1 
hg export -r first_local_change: > ../local1.patch 
```
转到新的本地资源库，创建feature分支所做更改导入，然后将它们导入：
```
cd ../local2 
hg branch feature 
hg import ../local1.patch 
```
hg import必须使用分支信息在补丁文件的选项，但默认情况下它是禁用的。