合並功能分支以釋放分支而不是主干

Question

我對兩個具有功能分支和發布分支的源代碼控制方案有疑問：

• 在方案1中，功能分支合並到了主干。
• 在方案2中，功能分支合並到最新版本的分支。

與方案1相比，方案2的后果是什么？

這兩種情況的可能優點和缺點是什么？

---

兩種情況的更多詳細信息：

• 所有開發都在功能分支中完成
• 分支總是從主干完成的

場景1（類似於此SO-answer中描述的場景）：

• 功能分支始終合並到主干
• 開始准備新版本時 ，將從主干中創建一個新的版本分支
• 從發布分支進行質量檢查和部署后，發布分支中的更改/錯誤修正將合並到主干和較新的發布分支中
• 對主干的更改將合並到所有功能分支

方案2：

• 功能分支始終合並到最新版本的分支
• 當當前發行分支不再接受新功能並且開始准備最終發行時，會從主干創建一個新的發行分支
• 從發布分支進行質量檢查和部署后，發布分支中的更改/錯誤修正將合並到主干
• 對主干所做的更改將合並到所有功能分支和最新發布的分支中

Answer 1

由於分支完全是關於隔離的 （請參閱“ 何時分支” ），因此兩種方案之間的區別是希望主分支trunk具有以下角色 ：

• 方案2更適合靜態角色 ： trunk將表示生產中的產品（偶爾需要將修補程序合並回當前功能和下一發行版分支）

• 場景1更適合於動態角色 ： trunk是各種功能的集成，從那里創建了發布分支以合並功能，這些功能實際上將成為下一版本的一部分。