版本控制分支策略 - 中型團隊和頻繁版本

Question

我們是一個由10名開發人員組成的中型團隊（每個項目有3名開發人員），並且想知道哪種版本控制策略是最優的。

已經對此進行了重大的研究，發現「Branch on release」是有意義的。然而，我們之前實施了這個方案，發現它每兩週發佈一次就會帶來很大的開銷。

幾乎沒有提到的一種模式是使用標籤按需分枝。它的工作方式是在每個發行版上標註代碼並對其進行快照，以便從中進行測試和發佈。然後，只有在生產中需要修復的缺陷時才能進行分支。

我已經繪製了一張圖表，說明了這種方法，該方法也將功能上的分支合併到跨多個衝刺。

在每次登記時，代碼將被擱置以進行代碼分析，在包含在中繼分支中之前編譯成功並進行代碼審查。

有沒有什麼缺點我不知道？爲什麼這種方法不會更廣泛？

Answer 1

我相信在TFS中以這種方式使用標籤的主要缺點是標籤沒有版本。如果有人刪除/更改標籤，除非您保留標籤的複印/備份，否則無法將其取回。如果你確實遵循這一點，請保留標籤內容的記錄，以便在必要時重新創建。

Answer 2

我不知道這種方法有任何主要問題。

我建議定期合併從幹線到分支，以阻止它們與幹線代碼分離得太遠。這在長期生活的分支上尤爲重要。

可以使用持續集成來自動執行此操作，比方說，如果合併造成衝突，則每晚調度一次合併失敗。當你將分支摺疊回樹幹時，這將避免最後的討厭合併。