​

簡介

在團隊協作開發中，版本管理工具尤為重要，它可以幫助團隊很好地進行程式碼的共享、回滾等操作，比較流行的版本管理工具有：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，分享程式設計師如何轉行產品經理、專案經理

本文來自部落格園，作者：技術管理修行，轉載請註明原文連結：https://www.cnblogs.com/jjglxx/p/15133603.html