成熟的 Git 分支模型

LieBrother發表於2018-12-22
Git模型

個人部落格原文： 成熟的 Git 分支模型

成熟的 Git 分支模型

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

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

gitmodelpng

閒言

在學校不管是自己寫課程設計還是給老師做專案，有 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 分支模型，在不管工作上還是學習上，在需要分支管理的時候，回憶起有這麼一個圖，根據你的場景再應用進去，肯定會少走很多彎路。

公眾號

相關文章