我會給出與Adarsh Shah相同的建議，因為在大多數情況下，2個分支(MAIN，RELEASE)就足夠了，并且使用feature branches用于你不想立即提交到MAIN的東西，因為它需要一段時間才能完全準備好測試 . 通過RELEASE，我指的是每個實際版本的分支 .

請記住，從理論上講，MAIN應該隨時處于釋放就緒狀態 . 這意味著使用特征分支也可以進行大量的小改動，只要該功能不被認為是準備好的，就不會將東西合并到MAIN中 . 現在，您應該嘗試這一點，看看哪種方式最適合您的環境 . 如果您發現將MAIN保持在發布就緒狀態太難了，請務必創建一個單獨的DEV分支來提交日常工作 . 然而，根據我的經驗，通過一些良好的指導，自動和手動測試，您可以快速進入MAIN可以被認為非常穩定的流程 . 我曾經在我們有一個非常不穩定的DEV分支和一個穩定的MAIN分支的環境中工作，以及我們沒有DEV分支的環境 . 有時需要DEV分支，有時它會使它們保持同步，因為DEV和MAIN都相當穩定，基本上只是彼此的副本 .

現在，何時應該創建發布分支 . 這取決于您正在進行的開發類型 . 對于小型桌面項目或具有相當穩定的發布周期的網站(例如，每個sprint發布一個版本)，我發現在sprint結束時創建一個發布分支最容易，之后只能將其推送到 生產環境 sprint .

S1 - - S2 - - S3 - - S4 // Each sprint

\ R1 - \ R2 - \ R3 // Release branch created at the end of a sprint

\ P1 - \ P2 // Pushed to production at the start of the next sprint

因此，在S1結束時，我從MAIN創建了發布分支R1，但它尚未推向 生產環境 階段 . 在S2期間，兩個新功能都在MAIN上實現，并且關鍵錯誤在R1上得到修復 . 如果R1上的修復程序被批準，它也會被合并回MAIN，如果需要的話 . 在S2結束時，創建一個新的R2，并將R1推入 生產環境 環境 . 我發現這種方法很有效 . 你基本上有一個完整的sprint來解決發布分支中的最后一個問題 .

當然，如果 生產環境 中出現嚴重的關鍵錯誤，則此錯誤優先于其他所有錯誤 . 然后可以創建正在 生產環境 的現有R分支的RXa，RXb，...分支，實現熱修復并將該熱修復推送到 生產環境 中 . 然后你可以考慮是否需要它將熱修復中的更改合并到MAIN分支中 . 不要在MAIN分支上創建一個熱修復并將其合并，但是你會發現它很快變得太復雜，因為在MAIN上很多周圍的代碼可能已經改變了 .

總結

以上是生活随笔為你收集整理的java任务分支和合并_合并/分支战略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。