成熟的 Git 分支模型

我的博客原文： 成熟的 Git 分支模型

今天介紹一下工做中會用到的 Git 分支模型。

先貼上圖以表敬意，圖片來自：A successful Git branching model

閒言

在學校不論是本身寫課程設計仍是給老師作項目，有 2 到 3 我的一塊兒協做開發時就會使用 Git ，可是隻是簡單用了它所提供的代碼協做功能，在學校的項目，好比課程設計，開發完老師檢查完就沒有維護了，給老師作項目也是，基於項目的特徵：沒有持久性、一次性開發，因此沒有應到 Git 分支模型。在企業中，一個應用每每是有比較長的生命線，由不少個迭代項目開發構成，這時要解決幾十甚至幾百人的代碼協做問題，就須要一套完整的規範的代碼開發流程。

我還記得當初大四的時候，去了一家企業實習，當時小團隊只有 3 個開發人員，git 使用沒有規範，只有一個 master 主分支，項目也沒有管理規範，來一個需求點就作。當時常常出現代碼覆蓋，各類代碼合併，線上代碼也不知道是哪一個節點的代碼。。。到我走的時候，也沒使用上這個分支模型。畢業後入職了某銀行，不說分支模型了，Git 都沒用上，直到今年跳槽到互聯網公司才瞭解到這個分支模型。所以，你工做不必定會真正用到這個分支模型，若是是在互聯網企業，頗有可能會使用上。

有些小夥伴看到這張偌大的圖以爲有些暈，很認真地說，這是一張你們都在用的圖，特別是互聯網企業。若是是尚未工做的小夥伴，可能有些陌生，沒事，咱們來看一下這些內容。

分支介紹

master ：這個分支的代碼是發佈到生產的代碼

develop ：這個分支的代碼是預發佈到生產的代碼

release ：這個分支的代碼是新版本發佈到生產的代碼

feature ：這個分支的代碼是新需求開發的代碼

hotfix ：這個分支的代碼是緊急修復生產 bug 的代碼

場景設想

下面列舉一些可能你在工做中會常常面對的場景

1. 組長分配新需求下來，安排下週上線（假設是 1227 號），你看看當前有沒有下週版本的分支？有的話很簡單，checkout 下週分支（feature_app1.1.0_1227）來開發就行，沒有的話這時須要新建分支，從 develop 分支建立新的 feature 分支（feature_app1.1.0_1227）,而後將對應的 pom.xml 版本號修改爲 1.1.0-SNAPSHOT，注意命名，好比這裏我用 feature 作前綴，你也能夠本身設定一個規則。

2. 開發完 feature_app1.1.0_1227 需求，移交了測試，很遺憾，測試出現了 n 個 bug，這時依舊在 feature_app1.1.0_1227 上修復 bug。

3. 終於到了發版前一天，測試 MM 說 n 輪測試完了，沒問題，拉上線版本，再作一次迴歸測試。這時，你就須要把 feature_app1.1.0_1227 分支合併到 develop 分支，而後從 develop 分支中建立新的分支 release_app1.1.0_1227，而後修改對應的版本號爲 1.1.0-RELEASE。

4. 到了發版日早上了，測試 MM 用了 release_app1.1.0_1227 版本測試了一番，又發現了一個 bug。別慌，只要不是生產的 bug，都好解決。這時你要在 release_app1.1.0_1227 修復 bug，切記不能在 feature_app1.1.0_1227 上修改，feature_app1.1.0_1227 分支已經沒有多大做用了，只用來看代碼提交記錄。

5. 安安全全的到了晚上，開始發版了，發完版忽然發現了有異常，定位問題後發現是有一行代碼寫錯了，跟組長確認後，在 release_app1.1.0_1227 分支上作了修改，從新打包後發版，驗證了一段時間，沒問題了。。。

6. 發版總算完成了，這時，別忘記把 release_app1.1.0_1227 版本合併到 develop 和 master 分支。還有一點很重要的，把 develop 分支代碼合併到 1227 之後的版本（若是已經有1227 之後的版本的話）。注意：這個步驟合併代碼要謹慎，若是有別人的代碼合併衝突比較大，須要找那個開發的同事一塊兒合併代碼。總算能夠睡個好覺了。。。

7. 告別了舊需求，迎來了新需求，接下來的需求開發就按上面的步驟走。。。

8. 次日，忽然生產上一直報 NullPointerException，定位發現是一行代碼沒有判空致使的，三番確認，原來這個數據之前是不爲空的，如今確實須要支持有些數據爲空的，須要緊急修復這個 bug，和組長確認以後，從 master 分支上拉了一個 hotfix_app1.1.1_1228 分支代碼，修復了 NullPointerException，打包後上線，驗證沒問題後，把 hotfix_app1.1.1_1228 分支合併到 develop 和 master 分支，並把 develop 分支合併到 1227 之後的版本。

好了，一大坨的文字描述了基於分支模型開發的過程。不一樣公司在應用過程當中可能會有些微小的不一樣，可是總體流程都是差很少的。好比有的公司可能會把 release 合併到 master 後，用 master 代碼發佈到生產，發版當時有異常，再從 master 分支上拉 hotfix 分支進行修復。上面描述的步驟就不同了，發版時出現異常，直接在 release 上修復。這些小的差異就不用計較太多啦。

但願本文可以讓你認識到有這麼一個標準的 Git 分支模型，在無論工做上仍是學習上，在須要分支管理的時候，回憶起有這麼一個圖，根據你的場景再應用進去，確定會少走不少彎路。