使用Mercurial的分支功能工作流程

我們有10位開發人員組成的團隊，他們爲不同功能並行工作，有時這些功能在某些時候使用通用代碼。現在，我們正在改變我們的流程以支持每個功能，看起來mercurial更適合這種開發。使用Mercurial的分支功能工作流程

我看到這個過程，以便：從默認 1.化妝發佈分支（RB）從默認（主幹）（主幹） 2.化妝特性分支（FB）

當開發者認爲他的特點是做了他可以將fb合併到rb。當到QA的時候，我們將所有已完成的f-b合併到r-b中，併爲我們的QA創建發佈。

問題：

QA時發現了錯誤開發商應該修改他的F-B和再次將其融合R-B。這是否意味着開發人員只需切換到他的f-b並開始修復該bug，然後再次將簡單的合併f-b轉換爲r-b？
當釋放通過QA它去PROD - 我們如何能夠凍結的變化？「hg tag」是不錯的選擇，但如果他真的需要，可以更新標籤。

感謝

來源

2011-10-09 Max Grigoriev

如果你要融入具體的發佈分支那麼你的功能分支應該從發佈分支被分支，不是主幹。合併父分支比非父分支合併更簡單。

1）如果你真的想做功能分支，那麼每個bug都會有自己的分支。這將有助於將錯誤修復與新功能分開。畢竟，它是按功能分支，而不是按開發人員分支。

2）汞標籤是我用過的。你是對的，如果有人願意，他們會移動一個標籤，但標籤是版本化的，你可以在主要的hg repo上安裝鉤子，以便在標籤被移動時發出警報。我真的不會擔心標籤被移動，除非你不能相信你的開發者，在這種情況下，你被搞砸了。

來源

2011-10-09 23:07:28

我們每週都會發布一次，並且很難知道F-b＃1是否會發布此版本的r-＃1。在這種情況下，我想將f-b＃1移動到下一個版本r-＃2或下一個下一個版本r-＃3。在這種情況下，開發人員只需在r-＃1之後從主幹更新他的f-b＃1（在發佈後我們將r-b合併到主幹以獲得最後穩定的主幹），並繼續工作。我不知道VSC認爲是否是一個很好的決定，但開發人員很容易理解，所有f-b都使用trunk，並且他們不關心f-b在哪個版本發佈。 –

1.我不喜歡Branch-per-bug，因爲我不需要這個分支 - 我需要很好的功能。再次，開發人員和構建主人在每個功能部門方面都很容易理解。在JIRA中很容易看到並查看功能問題狀態，並瞭解該功能無法集成到r-b中，或者它可以。但是，使用每個bug的構建主人應該找到所有相關的分支。但如果這是VSC管理歷史/合併/等的最佳方式，那麼我別無選擇 –

2.我看到 - 信任但驗證 –

您的第一個問題的答案是'是'。

凍結髮布的最好的辦法是有，只有發佈經理可以推/拉的變更到一個單獨的版本克隆。僅僅因爲你使用分支機構並不意味着多重克隆在你的工作流程中沒有位置。有一個QA可以進行最終飛行前測試的克隆，開發人員無法通過這些克隆進行更改，從而形成一個出色的防火牆。

此外，請考慮爲您的功能分支使用書籤。正如我確信你知道的那樣，Mercurial命名的分支名稱永遠不會讓類似git的書籤很好地處理像功能和錯誤這樣的生活概念。

來源

2011-10-10 03:07:49

書籤的好處是什麼？對於我來說，命名分支是更容易的事情，他們總是存儲在mercurial中。 –

好處，或者更確切地說，差異是它們的短暫性質。它們存儲在回購站中，它們可以被推入和拉出，但它們也可以被刪除。他們大多像「自動推進的標籤」。很多人發現命名分行對短暫的事情感到沮喪，因爲他們不可能被刪除。如果擁有1000個分支並不是你（這並不妨礙我），那麼命名分支就沒有問題。 –

我需要更深入地閱讀mercurial手冊以瞭解書籤的工作方式。你可以通過「hg commit --close-branch」刪除命名分支 –

使用Mercurial的分支功能工作流程

回答

相關問題