是否有一個特定的規則我應該用於何時在源代碼管理中進行分支？分支似乎很昂貴，因爲它們要求團隊對他們想要處理的功能的位置應該有更多的瞭解。什麼時候分支和什麼時候是錯誤的時間？
我們的開發團隊有時會發現自己的長期特徵和短期特徵同時工作。這意味着我們結束了：
幹線 分枝A（短期） 分枝B（長期）
後，他們完成我們到A合併到主幹，然後合併更改後備箱連接到B以確保這些編輯功能仍然有效。這很混亂。
我想知道如果我們可以通過使用標籤（或標籤，或引腳或任何您選擇的源代碼管理軟件調用它）來減少分支機構。也許這對長期項目的分支是有意義的，但是我們可以在向穩定版本應用標籤之後對短期項目進行編輯。這樣，如果我們必須執行緊急錯誤修復，我們總能檢索到穩定的源代碼，但我們不必處理分支。
您使用什麼規則來決定何時分支？
減少分支的一種方法是直接在主幹上實現新功能（尤其是小功能）。這是我們如何做到這一點：
首先，這取決於您使用的工具。在Subversion中，分支比Mercurial或git更「昂貴」，因爲合併很難做到。另一方面，它取決於你的項目/組織：你應該每個維護版本至少有一個分支。
在一個小團隊中，分支的時間是您無法直接進入中繼的時間。使用svn（正如我猜測其他版本控制一樣），可以推遲決定分支，直到意識到不能進入主幹。
爲了最大限度地減少分支需求，通過限制編譯時或運行時間標誌內的新特徵代碼，可以在trunk中對新特徵進行處理。這種方法還允許在不需要時關閉功能，使用功能進行A/B分割測試實驗等。
當然，使用這種方法時，始終有助於進行持續測試，在主幹上建立/測試套件中斷。
它取決於您正在使用的VCS。如果你正在使用一個支持合併的工具，那麼你應該在你喜歡的時候分支。如有疑問，請創建一個新分支。如果UNIX紀元的時間是偶數，那麼你應該分支。如果是，奇怪，你應該等一下，然後分支。如果您使用的工具不支持合併，那麼您應該考慮更換工具。換句話說，停止使用需要提出這個問題的工具。
對主幹線或幹線發展通常是不好的做法。中繼線應該用作主代碼集，並且應該反映當前代表生產的代碼。如果您還沒有投入生產，它應該代表黃金版本，應該始終構建並進行自動化迴歸測試。它不應該用來顯示發展狀態或活動。保護你的箱子免受變化，並抵制誘惑，讓開發人員檢查並鎖定箱子上的代碼。我認爲唯一的更新應該是通過合併過程，當你準備好將你的代碼返回到主線。 分支時，應考慮開發的目的，複雜性和持續時間。 •是否支持開發新功能或實質性開發的開發團隊？ •您是否在使用傳統流程或各種敏捷口味？ •這是爲了適應生產補丁或修補程序的開發？ •您將在分支上進行哪些開發，特別是測試活動，並且您會保留分支，直到派生的構件被構建，測試並視爲可釋放爲止？
這裏有很多模型，但很少有充分考慮「構建」過程以及再生可釋放工件的影響。
讓我們假設您有以下生命週期：DEV-> SYSTEM-INTEGRATIONTEST-> UAT-> PRE-PROD-> PRODUCTION。假設您從主線創建分支以適應開發和構建過程。您的開發\建立\測試循環繼續到UAT。從這個分支產生的文物已經接受了足夠的測試，認爲它們可能適合發佈。您可以聲明用戶簽署的工件也暴露在系統和集成測試中。
有些人主張此時將源代碼合併到主幹，並建議您在成功建立主幹時重新創建RELEASE分支。對我而言，如果解決方案穩定並且在生產之前不需要進一步更改，那麼這很好，否則您可能會在其他地方傳播錯誤。在不同的情況下，它需要改變。
如果您在PRE_PROD中發現問題，那麼這些「修復」更改將在哪裏進行？許多人建議您可以直接在發佈分支中更改代碼。如果繼續，這個修改會產生一個新的構建和一組新的構件。您可以選擇將這些工件通過PRE_PROD推回到生產環境，因爲基礎代碼已通過以前的測試進行驗證，並且爲穩定版本而進行的修改被認爲是無風險的？但是你有一個問題。
您無法說明發布到預產品和隨後生產的可執行文件\ artefacts已在您的較低環境中進行過測試。儘管信心很高，但發佈分支構建的輸出與開發構建產生的輸出不同。這可能會使審計失敗。
對我來說分支是關於管理你的代碼，而不是構建輸出或者只是發佈。如果您主張爲釋放和釋放穩定而進行分支（產前固定），則必須考慮上述風險以及對重要回歸測試的需求。
在主幹應該代表生產代碼的基礎上，除非已經推到生產線上，否則不能向其推送代碼。我主張創建一個支持開發，構建和發佈爲一個單一循環的分支。爲避免分支機構的壽命和不必要的幹線分歧（以及潛在的大爆炸衝突問題），儘可能限制發展並經常與幹線釋放和返回，以保持其他開發工作的最新狀態。