簡介
在團隊協作開發中，版本管理工具尤為重要，它可以幫助團隊很好地進行代碼的共享、復原等操作，比較流行的版本管理工具有：CVS、SVN、Git。Git作為分布式版本管理工具，優勢十分明顯，它可以為每位團隊成員本地提供一套完整的代碼庫，這使得開發者可以在無網的情況下将代碼送出至本地倉庫，減少了對中心伺服器的依賴。
随着Git的普及，為了更高效地進行團隊協作開發，人們通過經驗總結研究出了幾套适用于各種團隊和項目的分支管理政策，Git Flow 就是其中之一，它對版本控制更為嚴格，主要适合開發團隊規模較大、開發周期較長，可達幾周至幾個月的項目。接下來，直接展示最終實戰方案，如果開發團隊和項目類型适合，可直接拿來使用。
Git Flow 工作流圖
Git Flow 工作流說明
總體規範建議：
統一以版本号命名，各分支以版本号對應，比如，feature/v1.0 、release/v1.0、tag/v1.0
1. 主分支 Master
穩定版本代碼分支，不能在此分支直接修改代碼， 隻接受 hotfix、release 分支的代碼合并，每次從 release/hotfix 分支合并必須打版本号 tag，以友善後續的代碼追溯。
2.主開發分支 Develop
每個feature疊代從 develop 拉取分支，該分支隻接受 hotfix、release 分支的代碼合并，該分支禁止直接合并到 master。
3.新功能分支 Feature
新功能疊代開發分支，開發人員開發完成後合并生成預釋出分支 release/xxx（與 feature 分支一一對應），此分支禁止測試、禁止釋出上線、禁止直接合并到 develop、禁止直接合并到 master。
4.預釋出分支 Release
feature 分支由開發自測完成後合并到 develop 分支，測試人員再從 develop 分支建立對應的 release 分支。測試部進行內建測試、開發部修改 bug、産品驗收。測試通過後（釋出上線前）将此分支合并到 develop 和 master 分支，然後可将 release 疊代和對應的 feature 疊代分支删除。
5.熱修複分支 HotFix
該分支基于 master 分支建立，用于修改線上發現的緊急 bug， bug 修複完成并測試通過後需要合并回 master 和 develop 分支。
總結
以上是真實項目中的 Git 版本管理政策，其經過了實戰的考驗，可以拿來即用，我們可以看到上述政策較為繁瑣，需要同時維護 master 和 develop 兩個主要分支，是以，Git Flow 政策隻适合團隊規模較大，項目開發周期較長的項目，這個周期可以是幾周至幾個月，而現代的開發模式中，為更快更好地滿足客戶的需求，往往采用靈活疊代的開發方式。
接下來，我将更新一篇适合靈活管理團隊的版本管理政策，供大家參考。
關注微信公衆号
程式員職業生涯規劃，分享程式員進階架構師所需全部技能，分享程式員如何轉管理做技術總監、CTO，分享程式員如何轉行産品經理、項目經理
