源代碼控制分支策略

Question

我們正在嘗試確定在工作中使用的最佳源代碼控制分支策略。我們使用連接到GIT後端的VSO前端。我們有4個數據庫環境，DEV，QA，STAGE和PROD。在任何時候，除了大量正在進行的數據庫清理工作（添加主鍵和外鍵，將列設置爲非空值等）之外，我們有許多團隊正在處理不同的功能，這些功能經常會跳過對方，而且還有很多不同的功能

我的想法是爲每個數據庫環境維護四個持久分支，以反映其各自的數據庫環境。任何開發新功能的團隊都將從Dev分支，並且在完成工作後，合併到持久DEV分支中。當工作準備好進行質量檢查時，它將被合併到質量檢查中，在它準備移動到STAGE時它將被合併到STAGE等等。任何非破壞性的數據庫更新都不依賴於某種特性（比如使列非NULLABLE）可以作爲變更集流動而不需要特性分支，但是每個潛在的重大更改都需要作爲特性分支工作。

有沒有人使用過這種策略？它有用嗎？ 有更好的分支模型，你可以推薦？

Answer 1

那麼，因爲沒有人結束回答，我會用我自己的答案進行更新。看起來我們最終會使用這種分支策略，或多或少像我最初描述的那樣。主要區別在於PROD分支將被稱爲主分支，並且功能分支將從主分支而不是DEV分支。

這是因爲主/ PROD分支被認爲比DEV更穩定。從DEV成功分支出來的先前的環境是一個發佈版本。既然功能預計會在這裏跳過對方，我們不能這樣做。

此外，所有的開發都需要在功能分支中完成。這是由於VSO GIT插件的限制，然而，由於鏈接GIT的機制推送到VSO票據需要在功能分支中完成工作。