[[390059]]

關于Git分支管理，每個團隊在不同階段都有自己的管理策略，最近我們團隊也爭論過這個問題。

據了解，我們團隊以前采用的是版本分支管理策略，也就是每次上線新版本都會創建一個新的版本分支，而新的需求開發也從當前最新的版本分支遷出一個新的需求分支開發，線上bug則在版本分支上修改然后發布。

在我接手項目的時候發現一個問題，由于拆分的微服務項目以及組件不在同一個project里面，我拉取全部項目代碼后全部切換到master分支居然構建失敗，提示xx類沒有xxx方法，然后我全部切換到test分支情況依舊。后面同事找出的原因是新版本的代碼沒有合并到master分支。顯然，版本分支成了項目的主分支，而master分支相當于一個棄用的分支。

由于項目目前全部容器化部署，并且走自動化部署，因此版本分支已經不適用了，目前采用的策略是線上master分支，測試test分支，當開發完成需求后將需求分支合并到test分支交給測試的同事去測試，測試完成后由開發合并到master分支部署。

這種策略同樣存在問題，首先，開發不應該有權限修改master分支，其次，多個需求一同合并到master分支出現沖突會影響發布。

在發布新版本之前，我們應該確保已經解決所有代碼沖突問題，因此應該多出一個分支，只有該分支的代碼可以直接合并到master分支，所有需要在下個版本發布的需求分支通過測試后都應該先合并到該分支，在上線前再由項目負責人發起合并到master的請求，由部門主管處理合并請求，或者由項目負責人直接處理合并。

我并不看好自動觸發構建發布生產環境這種策略(代碼一合并到master分支就自動發布)，因為往往在發版之前都需要做一些準備，等所有準備就緒后再按順序去發版，例如數據庫表結構的修改、配置文件的修改(開發人員不應該拿到生產環境的配置)。

此外，自動觸發構建發布生產環境也不支持藍綠/灰度發布，當然了，我們項目目前也不需要藍綠/灰度發布，所以說，每個團隊在不同階段都有適合自己的管理策略。

以下分享筆者前后就職的三個公司當時采用的分支管理策略。

目前我們團隊使用的分支管理策略

• 生產分支：master
• 測試分支：test
• 需求分支：${需求}

開發人員開發需求需創建需求分支，需求開發完成后合并到test分支，測試人員在test分支上測試。

測試人員提交bug后，開發人員需切回需求分支修復bug，修復完成后合并到test分支，如此往復。

需求測試通過后，由開發合并到master分支發布。

線上bug直接在master分支修改，修改完成在master分支發布。

這種方案直接在master分支修復線上bug繞過了測試，而且每個開發都有master分支的提交權限，存在很大的風險，因此這種方案只適合小團隊。

老東家使用的分支管理策略

• 開發分支：dev
• 生產分支：master
• 測試分支：test
• 需求分支：${需求}
• 版本分支：relese-${version}

開發人員開發需求需創建需求分支，開發完成后由測試人員切換到該需求分支測試，或者批量測試的話就將多個需求分支合并到test分支。

測試人員提交bug后，開發人員需切回需求分支修復bug，修復完成后再通知測試人員切換到該分支測試，或是合并到test分支測試，循環往復。

需求測試通過后，由開發人員/開發組長將需求分支合并到dev分支，在約定的版本上線時間由開發組長提交將dev分支合并到master分支的請求，由主管合并分支。

最后，每次發版之后都將dev切出一個relese-${version}分支，線上bug在此分支修改，并且修改完成后測試需切到該分支測試，測試完成后就可以直接合并到master分支發布。

前前公司使用的分支管理策略

無分支管理策略，沒有測試環境，需求在需求分支開發，開發完成后由開發自己測試，覺得沒問題了就直接合并到dev分支，然后發布。master分支也是棄用的。有些簡單的需求以及線上bug都是直接在dev分支改動。(沒有測試就直接上線，非常的恐怖)。

本文轉載自微信公眾號「Java藝術」，可以通過以下二維碼關注。轉載本文請聯系Java藝術公眾號。