有關git版本管理和混亂的建議

Question

我們是一個由6名開發人員組成的團隊，並且已經從TSVC（在TFS2010上）過渡到git（在Gitlab上）已有近一年的歷史了。 我們采用了http://nvie.com/posts/a-successful-git-branching-model中的發布模型，該模型正在運行，但有時會努力適應。

背景：我們僅為1個獨家客戶維護一個內部網絡應用。 通常，我們有2種發行版本：

• 次要：錯誤修正和少量更改請求
• 主要：主要變更請求，通常需要幾個月的時間才能交付

這兩種類型的發行版都只能在客戶批准后才能部署到生產中。

我們有4種分支， master ， release ， develop和topic分支。 一旦發布准備好了，我們就會從master分支出一個新版本。 對於CR，我們最初從分支develop ，雖然后來我們發現，這是相當多余的，因此，我們現在從分支master 。 主題分支是錯誤修復和小型CR，是正在進行的release或master分支的分支。 當我們將足夠的錯誤修正合並到release分支中時，或者當需要發布緊急錯誤修正時，我們將准備release該release分支，並開始一個新的release分支。 我們通常每兩周或每月在固定的工作日發布一次。 我們還通過在每個發行版中合並次要release release分支來更新主要release release分支。

我們使用Gitlab的CI在每次推送時構建我們的軟件包，並將最后構建的軟件包部署到我們的測試環境中，以供我們的測試團隊進行測試。 當release分支穩定時，最終的軟件包將通過測試並獲得客戶批准的發布，然后將同一軟件包用於生產部署。

以下是我們的一些困惑。

1. 由於我們總是從release分支的頂端進行部署，因此我們認為無需將其合並回master 。 將release合並到master release的提交不是已部署的提交。 如果我們要使用最終的合並提交，那么我們將不得不再次經歷測試周期，這似乎是多余的。 我們還應該保持master嗎？
2. develop分支似乎也不適合我們的工作流程，我們也應該刪除它嗎？

最后，似乎對我們有用的只是擁有次要和主要release分支，但是我們想知道這是推薦的方法還是可以遵循的更好的發行模型。

Answer 1

我們與您進行相同類型的開發。

對於我們來說，Dymitruk的分支模型http://dymitruk.com/blog/2012/02/05/branch-per-feature非常理想。 簡而言之，它取消了development和release分支，僅使用master ， featureXXX ， qa （預發行測試）和ci （連續集成）分支，最后一個是技術性更高且相當可選的分支。

該系統嚴重依賴git rebase和git rerere ，因此僅適用於git （我不知道是否有其他VCS具有類似rerere東西），並且非常干凈和強大。