[[390059]]

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

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

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

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

這種策略同樣存在問題，首先，開發(fā)不應(yīng)該有權(quán)限修改master分支，其次，多個需求一同合并到master分支出現(xiàn)沖突會影響發(fā)布。

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

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

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

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

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

• 生產(chǎn)分支：master
• 測試分支：test
• 需求分支：${需求}

開發(fā)人員開發(fā)需求需創(chuàng)建需求分支，需求開發(fā)完成后合并到test分支，測試人員在test分支上測試。

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

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

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

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

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

• 開發(fā)分支：dev
• 生產(chǎn)分支：master
• 測試分支：test
• 需求分支：${需求}
• 版本分支：relese-${version}

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

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

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

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

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

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

本文轉(zhuǎn)載自微信公眾號「Java藝術(shù)」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系Java藝術(shù)公眾號。