命名以前未命名的分支

看來命名以前未命名的分支並不真正解決問題。它創造了一個我無法找到解決方案的令人討厭的多頭問題。命名以前未命名的分支

這裏是工作流程...

用戶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必須使用分支信息在補丁文件的選項，但默認情況下它是禁用的。