不將發布分支合並到Trunk會給我帶來什么好處？

Question

TLDR; 我的團隊的SVN分支策略不會回到主干。 這感覺就像一個反模式，我無法立即解釋原因。 這是一個問題嗎？這些問題是否足以推動變革？

細節-

我的團隊商定的分支策略是創建月度發布分支。 通過將.ear文件交給另一個團隊進行部署來處理版本 - 不將它們指向我們的SVN存儲庫。

在進入每個分支的生產之前，我們保留最后一次提交的標記，供以后使用。 我們每天都建立一個開發環境來捕捉破壞的構建。

但是當我們為下一個版本創建一個分支時，我們從現有的發布分支分支 - 並且永遠不會返回或與Trunk交互。 對分支發布版本的任何分支后更改都會合並，直到最新版本完成。

Trunk
|\
| April
|      \
|       May
.          \
.           June...
.
.

我們在項目分支方面遇到了問題，這些問題已合並到預計將推出的版本中。

我們不使用功能分支，因此從發布中回滾或刪除更改是一件麻煩事，因為每個發布分支都是開發和錯誤修復分支。

除此之外，是否存在受此分支策略影響的基本SVN功能，對存儲庫的不良影響或其他風險？

Answer 1

正如你所說，我可以想象“回滾或刪除發布中的更改是一件令人討厭的事情”，但仍然可行。

當您使用此SVN設置雇用新的新開發人員時，您將失去寶貴的時間。 他們將更難以學習，貢獻和故障排除這個存儲庫。 以同樣具有可讀代碼的重要方式，擁有可讀存儲庫很重要。

如果您的團隊遇到存儲庫問題，那么從書籍，網站和其他人那里尋求外部建議將更加困難。

如果要將任何類型的第三方軟件合並到存儲庫中，則可能很難，因為已忽略使用中繼的SVN約定。

您的存儲庫組織似乎受到每月節奏的尷尬限制。 如果您需要在一個月內完成兩個代碼滾動怎么辦？ 你創建半個月的分支嗎？

您的團隊缺少SVN標記的概念。 標簽是不需要編輯的最終版本。 這些標簽通常具有類似Application-1.2.3的版本號。 版本號是整數的三元組：MAJOR.MINOR.PATCH。 這向開發人員表明應用程序的變化有多大，以及一個版本與另一個版本的差異程度。

看看這本在線書籍，我發現它很有用：
http://svnbook.red-bean.com/en/1.8/svn.basic.html