當涉及到向穩定分支引入新功能的商務過程時，我們有以下要求。
我們有一條穩定的生產線交付給我們的客戶。我們還有一個開發線，開發新功能。有時候，我們認爲我們需要將一些開發的功能引入穩定版本。並非全部，但其中一些。如何組織分支（我們使用的是mercurial），以便我們可以選擇我們想要應用於穩定分支的功能？
另一方面，我們需要有一個分支，我們將所有功能集成到一個分支中，稱之爲dev分支（它來自穩定分支）。穩定分支的櫻桃採摘新功能
其中一個想法是有一個穩定的分支，開發分支（這是從穩定一次派生）和每個功能的獨立分支。
錯誤在穩定的分支上解決，並不時地將更改拉到其他分支（開發和功能的分支）。一旦做出將特定特徵集成到穩定分支的決定，則只有給定特徵分支與穩定分支合併。另外，功能分支有時也會在開發分支上提供（用於集成正在開發的所有功能）。
您的潛在解決方案將起作用，並且與GitFlow非常相似，可以很容易地將其應用於mercurial。
碩士將是你的穩定分支（大概是'默認'），並且你正在優先發布分支，根據你的開發/測試過程，這可能是一個好的或壞的想法。無論哪種方式，標籤發佈都是一個好主意。
您可以將您的功能分支定期合併到您的開發分支，而不是將完成的功能合併到開發中，然後將它們傳播到您的其他活動功能分支。如果您的優先級發生變化（當然，完成您的集成測試後），這使您可以靈活地提前發佈已完成的功能。如果您定期將不完整的功能合併到開發分支中，如果突然決定已經完成的功能需要儘快發佈，您將難以找到安全的發佈點。如果您對與他們的集成問題特別謹慎並且希望儘早地捕捉它們，您仍然可以選擇將功能分支直接合併到另一個功能分支中。
使用Gitflow中概述的修補程序/維護分支將允許您維護'stable'分支的神聖性。您可以爲每個單獨的修補程序分支，將其合併回去並在完成時關閉分支，或者保留一個正在進行維護的分支，這必須與Stable保持同步。我更喜歡每個修補程序的分支靈活性。
另外，對於短期分支，例如小功能或修補程序，您可能會考慮使用Bookmarks，但這取決於您對更改歷史記錄的感受。
假設你必須經歷一個被認爲是「穩定」的更改的測試階段，那麼你將無法直接在stable上進行錯誤修正並認爲它是穩定的，除非你正在測試在dev上進行的構建上的潛在修復機器，然後發佈到您的共享回購。 – Kindread 2014-10-03 20:49:23
yap，錯誤修復是在開發機器上進行的構建上測試的，但暫時忘記了穩定分支的名稱，我剛剛以這種方式作爲示例調用它。 – 2014-10-06 00:50:48
我在下面的答案仍然適用，但是您可以放棄維護分支機構，但對於需要更長時間的修復，我至少仍會使用書籤。 – Kindread 2014-10-06 05:03:53