0
我們有一個歷史上遭受過大量分支機構的應用。並行工作和「突破性變化」的分支策略
這些已經得到批准，但現在已經出現了一種情況，即我們有兩個開發流（理想情況下是一個開發流），其中一個流需要進行一些更改，其中實施它們會產生影響，作爲單一故事的一部分（或可能是單一的衝刺）。
例如：需要大量查詢邏輯更改的大量數據庫模式更改。
這些更改不容易標記功能，因爲它們系統地破壞現有功能，直到完成工作。理論上我們可以將系統重新置於「建築」狀態，但這會阻止客戶使用現有的功能。
爲了迎合這一點，我們建議爲'突變'創建一個新的分支，以便其他開發流不被打破，並且可以間歇性地發佈。
雖然我很討厭創建新的分支機構，但目前看不到這樣做的更好方法。
有沒有推薦的做法，要麼是分支策略管理，要麼是體系結構保護，打破並行開發中的變化？
編輯：已經越過我心中唯一的另一件事是字面上「複製 - 粘貼」現有的功能（包括表/網頁等），對其進行重命名，並在同一個分支上的工作，後面的功能旗。 由於多種原因，這顯然很麻煩！
有沒有人對他們過去如何應對這個問題有任何建議？
在理想的世界裏，當然。導致我們遇到問題的原因在於，對於一個sprint而言，模式更改太大，因此需要對現有區域進行大量更改。 這些變化的衝擊對DAL，BLL和UI同時具有重要意義。 主要問題是，在這種情況下，確保我們可以遞增遞送所需的努力量是巨大的，相比之下，允許「行李箱」在一段時間內變得不穩定。鑑於此，你會建議單獨的分支可能是兩個邪惡中的較小者？或者你會努力在單個分支上實現嗎？ – dougajmcdonald 2015-01-21 17:32:22
我不能打這個電話。只有你的生意可以。在重構過程中，您仍然需要爲客戶提供價值嗎？如果是這樣，你必須去＃1。否則，你會得到兩個不同的代碼庫 – 2015-01-22 05:30:29
你總是可以分解它。進行較小的更改。一次只能有一張桌子。 – 2015-01-22 05:31:34