​簡介

隨著Git的普及，為了更高效地進行團隊協作開發，人們通過經驗總結研究出了幾套適用於各種團隊和專案的分支管理策略，上篇文章我們講解了 Git Flow 程式碼版本管理策略，它對版本控制較為嚴格，主要適合開發團隊規模較大、開發週期較長，可達幾周至幾個月的專案，同時，文章提供了版本管理方案圖及必要的講解。

接下來將介紹Git 分支管理策略：TBD++ Flow，該版本管理策略整合了其他策略的優點，適合敏捷開發團隊，開發週期長、快速迭代均適用。先看一下工作流圖。

TBD++ Flow 工作流圖

TBD++ Flow 工作流說明

總體規範建議：

統一以版本號命名，各分支以版本號對應，比如，feature/v1.0 、release/v1.0、tag/v1.0、hotfix/v1.0

1. 主分支 Master

穩定版本程式碼分支，不能在此分支直接修改程式碼， 只接受 hotfix、release 分支的程式碼合併，每次從 release/hotfix 分支合併必須打版本號 tag，以方便後續的程式碼追溯。該分支上部署自動化測試指令碼，在每次程式碼提交至該分支後都會觸發測試，以此保證主分支核心功能的穩定。

2.新功能分支 Feature

新功能迭代開發分支，開發人員在此分支進行編碼及程式碼評審->測試人員進行功能測試->開發人員修復bug->從 master 分支拉取最新程式碼 ->將測試通過後的程式碼合併到 master。feature 分支需要定期向 master 分支拉取最新程式碼。

3.釋出分支 Release

feature 分支經過程式碼評審及功能測試後合併到 develop 分支，測試人員再從 master 分支拉取對應的 release 分支。測試部進行整合測試、開發部修改 bug、產品驗收。產品驗收通過後（釋出上線前）基於 release 分支打 tag 進行版本釋出，再將程式碼合併回 master分支，如果程式碼較為關鍵，還需要合併到其他的 release 分支。最後可將 feature 迭代分支刪除。

4.熱修復分支 HotFix

1）如果是在 master 分支發現的bug，則該分支基於 master 建立，bug 修復完成並測試通過後需要合併回 master 分支。

2）如果是在 release 分支發現的bug，則該分支基於 release 釋出時的 tag 版本建立，bug 修復完成並測試通過後需要合併回 master 分支、所有涉及的 release 分支以及 master 分支。最後在 release 分支上新增新的 tag。

總結

以上是敏捷專案團隊中所推薦的 Git 版本管理策略，我們可以看到上述策略比前文的 Git Flow 簡單了許多，少了一個主要的 develop 分支，只需要維護 master 一個主幹分支，現代的開發模式中，為更快更好地滿足客戶的需求，往往採用敏捷迭代的開發方式，TBD++ Flow 版本管理策略既適合週期較長的團隊開發，也適合快速迭代的開發模式，它整合了其他版本管理策略的優點，可以在敏捷開發團隊中使用。
敏捷開發團隊對團隊成員的每一位要求比較高，需要團隊成員能夠編寫自動化測試指令碼，也需要團隊中的每一位成員都能夠獨立合併自己的程式碼。

關注微信公眾號【技術管理修行】

程式設計師職業生涯規劃，分享程式設計師進階架構師所需全部技能，分享程式設計師如何轉管理做技術總監、CTO，分享程式設計師如何轉行產品經理、專案經理