Question

似乎命名一个以前未命名的分支并没有真正解决。它造成了令人讨厌的多头问题，我无法找到解决方案。

这是工作流程......

UserA开始处理他们期望的小功能，因此他们只是开始工作（在default分支之外）。这一变化原来是一个大型项目，需要多个贡献者。因此，UserA发布...... hg branch "Feature1"并继续工作，需要在本地提交。

UserA然后从中央仓库下拉变化，以便他可以推送。

此时，为什么hg heads返回 3 头？它为default显示2，Feature1显示1。 default的第一个头是分支上另一个用户的最新更改（不相关）。第二个default头是hg branch "Feature1"提交之前的提交。

中央存储库已实施规则，因此每个分支只允许1个头，因此强制推送不是一种选择。 repo不希望default分支上有多个头。

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

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

Answer 1

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

在我的示例中，UserA应该更新到default上不需要的头部并关闭默认分支，因为它是不需要的。这将为default留出2个头，按预期为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的变更集。

UserA应更新为defaul t的最新，不需要的变更集。然后在UserA开始工作之前将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分支，推送并继续工作。

Answer 2

您在本地仓库中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可以选择使用补丁文件中的分支信息，但默认情况下已禁用。

此时，您可以继续在原始位置使用新的本地仓库。此外，我会仔细检查以确保一切都在新的回购中。

Answer 3

我们发现这对我们的团队来说是一个非常大的问题（按功能进行分支）并最终停止了hgweb.cgi脚本的工作（HTTP 414请求太长）。

Answer 4

来自hg help heads：hg heads没有args将显示分支头，根据定义，分支头是在同一分支上没有子代的变更集。在这种情况下，hg heads --topo应该会为您提供所需的结果。

Answer 5

不要通过中央存储库。让你的开发人员互相拉扯。

命名以前未命名的分支

5 个答案: