該團隊的一部分正在開發下一個版本/ sprint，其他則負責測試並修復之前的sprint。計劃發佈分支
的部分在下一版本的工作現在想的分支，另一部分儘快希望它儘可能晚，因爲他們將不得不開始合併修復，因爲我們的分支。
我不喜歡讓任何人等待提交，因爲我們還沒有分支。當他們不理解合併時，我也不喜歡浪費人們的時間。 （和SVN不合並重命名）
有什麼意見或建議嗎？由於
注：
這是因爲我們使用TortoiseSVN的1.6與1.4回購其阻止了GUI從做分支/合併操作，在過去一個糟糕的問題。所以我通過升級回購消除了這個障礙。現在，團隊成員應該很容易合併。
爲您考慮的另一點：
請保留逐行代碼（最活躍使用的代碼被認爲是一個邁向新更新，最新版本的標題）在樹幹上。從HEAD分支出來（或者之前的基線版本，如果您已經標記了它的話）以供bug fixer團隊使用。他們可以定期修復錯誤並定期從主幹合併，以便從最新的開發中獲取更新（如果他們願意的話）。
，另一方面新版本工作進展的軀幹和行李箱可以專款專用，始終代表的是在「當前」或「生產」的環境。如果您想要將以前版本的修復恢復到curent版本，您可以從bugfix分支恢復到TRUNK。
該模型可以在下一個版本的標籤後進行迭代爲好。
在我的經驗，這有助於最大限度地減少合併爲bug修復將在數少所以這意味着較小的文件，並在需要時合併回主幹。在大多數情況下（我說絕大多數情況下都是:-)）的情況下，bug修復的開發人員數量會少一些，這意味着需要合併的文件數量較少。
HTH。
我強烈建議Git/Mercurial解決這些問題。 :)
但因爲我知道那不是一種選擇，我只想說，真的有沒有100％的巨大回答這些類型的問題。一般來說，我傾向於在分支過程儘可能晚的時候不支持分支，因爲與CVS/SVN的分支和合並往往是重量級的過程。您可以推遲分支流程的時間越長，您在許多方面就越好。但是，研究新功能的團隊知道，這隻能持續很長時間......在某種程度上，延遲新功能的成本超過了推遲合併的好處。
哪裏我現在，這往往是一個新版本的發佈結果公佈之前的一個分支1-2周（有時甚至更低）。但確切的時間總是隨着推動發佈的具體壓力以及即將發佈的新功能而變化。
分支不必在SVN一個痛苦的過程 - 尤其是在TortoiseSVN的最新版本和SVN客戶端。它需要一些關於VCS和回購的知識，但這對任何軟件開發人員都是必需的。
一些思考很多新的代碼，以及如何許多修改怎麼可能在開發的每個階段發生。通常情況下，sprint/release階段會產生比錯誤修復階段更大的更改集。這意味着立即分支併合並較少數量的錯誤修復程序會更加明智。在大多數情況下，等待分支會導致更混亂的合併。
早期的分支還可以讓您的錯誤修復更具有曝光度，因爲它們可以在單元和新功能的功能測試期間由短跑開發人員執行。更多曝光=更好的無錯修復。
一旦進入功能凍結髮布，您必須執行該分支，以便在下一個版本上工作的團隊不會繼續破壞您嘗試放置的那個團隊。試圖推遲一個分支比這更進一步會導致更多問題。
如果您使用功能分支，那麼這變得更容易。所有的修復都發生在trunk中，你保留一個RC分支，你可以從中發佈，你可以在做測試版本之前從trunk到批量合併。功能分支從主幹合併，只有在功能準備就緒後才能合併回主幹。雖然這聽起來像會導致更多的合併，但它使所有合併非常簡單。
這是類似的，你會得到一個DVCS，只是所有的樹枝都在衆目睽睽下，而不是圍繞開發者的機器傳播的工作流程。
分支儘可能晚。