成熟的 Git 分支模型
今天介紹一下工作中會用到的 Git 分支模型。
先貼上圖以表敬意
閑言
在學校不管是自己寫課程設計還是給老師做項目，有 2 到 3 個人一起協作開發時就會使用 Git ，但是只是簡單用了它所提供的代碼協作功能，在學校的項目，比如課程設計，開發完老師檢查完就沒有維護了，給老師做項目也是，基于項目的特征：沒有持久性、一次性開發，所以沒有應到 Git 分支模型。在企業中，一個應用往往是有比較長的生命線，由很多個迭代項目開發構成，這時要解決幾十甚至幾百人的代碼協作問題，就需要一套完整的規范的代碼開發流程。
我還記得當初大四的時候，去了一家企業實習，當時小團隊只有 3 個開發人員，git 使用沒有規范，只有一個 master 主分支，項目也沒有管理規范，來一個需求點就做。當時經常出現代碼覆蓋，各種代碼合并，線上代碼也不知道是哪個節點的代碼。。。到我走的時候，也沒使用上這個分支模型。畢業后入職了某銀行，不說分支模型了，Git 都沒用上，直到今年跳槽到互聯網公司才了解到這個分支模型。因此，你工作不一定會真正用到這個分支模型，如果是在互聯網企業，很有可能會使用上。
有些小伙伴看到這張偌大的圖覺得有些暈，很認真地說，這是一張大家都在用的圖，特別是互聯網企業。如果是還沒有工作的小伙伴，可能有些陌生，沒事，我們來看一下這些內容。
分支介紹
master?：這個分支的代碼是發布到生產的代碼
develop?：這個分支的代碼是預發布到生產的代碼
release?：這個分支的代碼是新版本發布到生產的代碼
feature?：這個分支的代碼是新需求開發的代碼
hotfix?：這個分支的代碼是緊急修復生產 bug 的代碼
場景設想
下面列舉一些可能你在工作中會經常面對的場景
組長分配新需求下來，安排下周上線（假設是 1227 號），你看看當前有沒有下周版本的分支？有的話很簡單，checkout 下周分支（feature_app1.1.0_1227）來開發就行，沒有的話這時需要新建分支，從 develop 分支創建新的 feature 分支（feature_app1.1.0_1227）,然后將對應的 pom.xml 版本號修改成 1.1.0-SNAPSHOT，注意命名，比如這里我用 feature 做前綴，你也可以自己設定一個規則。
開發完 feature_app1.1.0_1227 需求，移交了測試，很遺憾，測試出現了 n 個 bug，這時依舊在 feature_app1.1.0_1227 上修復 bug。
終于到了發版前一天，測試 MM 說 n 輪測試完了，沒問題，拉上線版本，再做一次回歸測試。這時，你就需要把 feature_app1.1.0_1227 分支合并到 develop 分支，然后從 develop 分支中創建新的分支 release_app1.1.0_1227，然后修改對應的版本號為 1.1.0-RELEASE。
到了發版日早上了，測試 MM 用了 release_app1.1.0_1227 版本測試了一番，又發現了一個 bug。別慌，只要不是生產的 bug，都好解決。這時你要在 release_app1.1.0_1227 修復 bug，切記不能在 feature_app1.1.0_1227 上修改，feature_app1.1.0_1227 分支已經沒有多大作用了，只用來看代碼提交記錄。
安安全全的到了晚上，開始發版了，發完版突然發現了有異常，定位問題后發現是有一行代碼寫錯了，跟組長確認后，在 release_app1.1.0_1227 分支上做了修改，重新打包后發版，驗證了一段時間，沒問題了。。。
發版總算完成了，這時，別忘記把 release_app1.1.0_1227 版本合并到 develop 和 master 分支。還有一點很重要的，把 develop 分支代碼合并到 1227 以后的版本（如果已經有1227 以后的版本的話）。注意：這個步驟合并代碼要謹慎，如果有別人的代碼合并沖突比較大，需要找那個開發的同事一起合并代碼。總算可以睡個好覺了。。。
告別了舊需求，迎來了新需求，接下來的需求開發就按上面的步驟走。。。
第二天，突然生產上一直報 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 分支模型，在不管工作上還是學習上，在需要分支管理的時候，回憶起有這么一個圖，根據你的場景再應用進去，肯定會少走很多彎路。
總結
以上是生活随笔為你收集整理的成熟的 Git 分支模型的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 口臭会传染吗
- 下一篇： HTTP的同源策略与跨域资源共享（COR