我有一個道德delema，在我的公司內，我們有我們的整個產品套件在主分支和項目將分支主幹（樹幹）分支。我遇到了一個問題，即要交付的衝刺（長達8周）已經推遲並且無法部署2周，但是開發需要繼續進行下一衝刺。TFS分支策略：發佈延遲並且開發持續。
問題是，如果在sprint 1中存在需要修復的bug，並且現有分支上的開發仍然存在，那麼bug修復和sprint 2的部分將會混合在一起，因此很難釋放sprint 1。
另一方面，如果我們從現有的分支創建一個新的分支，我們將釋放所有的任務和錯誤，而不是。
是否有代碼分支共享一個團隊項目的方式或者是愚蠢的？
你會如何處理這種情況？有什麼我失蹤了嗎？
如果你正在分支到一個新的團隊項目每衝刺，那麼你做錯了。一個產品的所有分支應該存在於同一個團隊項目中。
Sprint應與迭代對齊，而不是Team Projects，這樣您可以自由地將任何工作項從一個sprint重新分配給另一個，而不會出現問題。
如果這些錯誤很重要，那麼將它們修復到sprint 1分支並將它們合併到sprint 2中。這樣您就可以在沒有sprint 2代碼的情況下釋放它們。無論這是你最初的Sprint 1發佈的一部分還是將來的一部分。
如果錯誤並不重要，那麼您可以在sprint 2分支中修復它，併發布帶有錯誤的sprint 1。
沒有理由說衝刺和分支需要一對一排隊，如果你只發布每3個衝刺，那麼你可以輕鬆地離開，每3衝刺只分支一次。如果你擅長髮布管理，並確切知道發佈了什麼變更集，那麼如果你需要修改衝刺結果，甚至可以在發佈後的幾個星期內分發。
如果你想真正認真地進行持續部署，那麼你需要開始尋找具有中繼分支和功能分支的功能，只有當功能完成後才能將功能合併回主幹。每個sprint可能有幾個功能分支。或者關注功能切換，這意味着您可以部署新的代碼，但將其關閉，以便用戶不會注意到任何事情。