版本控制：在功能開發周圍移動bug修復/代碼增強

我有一個與Mercurial相關的工作流問題（可能適用於其他DVCS）。版本控制：在功能開發周圍移動bug修復/代碼增強

回購利用典型的默認/穩定設置進行設置。

您的任務是構建一項新功能，並期望它需要一些時間（月+）。在處理此功能時，您遇到了一個您認爲應該早日修復並應用於生產的錯誤。或者，您可能注意到一些可以更好地記錄的代碼。

我的假設是，您在默認情況下進行修復，然後切換到穩定狀態並再次進行修復（手動或通過應用修補程序）。這是正確的，還是應該立即切換到穩定狀態，在那裏進行更改，然後將穩定狀態合併到默認狀態？

使用補丁似乎對我更有意義。您可以專門針對錯誤修復進行提交，並在方便時應用該修補程序。我的意思是，如果這個bug不是太噁心，那麼就沒有必要緊迫並且打破流動。對？

那麼，你如何處理這種情況？

感謝

2011-01-13 jbarreiros

注意：Wim提出了一個可行的選擇櫻桃採摘，你可以考慮。 – VonC 2011-01-13 20:24:35

你可以回去向分支點（修訂B），修復bug存在（修訂X），然後合併修改爲兩個分支（M1和M2）：

-----B--o----o---M1----o---> stable 
    |  /
    |---------X bugfix 
    |   \ 
    \--o---o----M2----o-----> feature

這種方式可以用正常的hg merge操作在每個分支獲得修復;不需要修補，移植或MQ_ing。

採取同樣的想法更進一步：你可以回到首先引入錯誤的版本。通過將此用作修補程序的基礎，您可以確定可以將修補程序合併到包含該錯誤的任何分支中。

2011-01-13 20:05:06

一旦你取得了你的小補丁提交，你可以使用Hg Transplant Extension和報告上的另一個分支相同修復。

如果這不合適，在SO問題「Mercurial cherry picking changes for commit」中詳細描述了其他櫻桃採摘可能性。

2011-01-13 17:45:08 VonC

謝謝VonC，移植擴展可以做得很好。感謝您的鏈接了。 – jbarreiros 2011-01-13 18:19:04

可以通過更好的工作流程避免這種情況。下面的Wim的解決方案是可取的，因爲你不會用不同的hash-id在你的repo中進行兩次相同的更改。在兩個地方做出同樣的改變使得這些地方最終融合得不那麼自動。 – 2011-01-13 20:12:34

回答