Git 工作中怎么用？

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

先貼上圖以表敬意

閑言

在學(xué)校不管是自己寫課程設(shè)計(jì)還是給老師做項(xiàng)目，有 2 到 3 個(gè)人一起協(xié)作開發(fā)時(shí)就會(huì)使用 Git ，但是只是簡(jiǎn)單用了它所提供的代碼協(xié)作功能，在學(xué)校的項(xiàng)目，比如課程設(shè)計(jì)，開發(fā)完老師檢查完就沒有維護(hù)了，給老師做項(xiàng)目也是，基于項(xiàng)目的特征：沒有持久性、一次性開發(fā)，所以沒有應(yīng)到 Git 分支模型。在企業(yè)中，一個(gè)應(yīng)用往往是有比較長(zhǎng)的生命線，由很多個(gè)迭代項(xiàng)目開發(fā)構(gòu)成，這時(shí)要解決幾十甚至幾百人的代碼協(xié)作問題，就需要一套完整的規(guī)范的代碼開發(fā)流程。

我還記得當(dāng)初大四的時(shí)候，去了一家企業(yè)實(shí)習(xí)，當(dāng)時(shí)小團(tuán)隊(duì)只有 3 個(gè)開發(fā)人員，git 使用沒有規(guī)范，只有一個(gè) master 主分支，項(xiàng)目也沒有管理規(guī)范，來一個(gè)需求點(diǎn)就做。當(dāng)時(shí)經(jīng)常出現(xiàn)代碼覆蓋，各種代碼合并，線上代碼也不知道是哪個(gè)節(jié)點(diǎn)的代碼。。。到我走的時(shí)候，也沒使用上這個(gè)分支模型。畢業(yè)后入職了某銀行，不說分支模型了，Git 都沒用上，直到今年跳槽到互聯(lián)網(wǎng)公司才了解到這個(gè)分支模型。因此，你工作不一定會(huì)真正用到這個(gè)分支模型，如果是在互聯(lián)網(wǎng)企業(yè)，很有可能會(huì)使用上。

有些小伙伴看到這張偌大的圖覺得有些暈，很認(rèn)真地說，這是一張大家都在用的圖，特別是互聯(lián)網(wǎng)企業(yè)。如果是還沒有工作的小伙伴，可能有些陌生，沒事，我們來看一下這些內(nèi)容。

分支介紹

master ：這個(gè)分支的代碼是發(fā)布到生產(chǎn)的代碼

develop ：這個(gè)分支的代碼是預(yù)發(fā)布到生產(chǎn)的代碼

release ：這個(gè)分支的代碼是新版本發(fā)布到生產(chǎn)的代碼

feature ：這個(gè)分支的代碼是新需求開發(fā)的代碼

hotfix ：這個(gè)分支的代碼是緊急修復(fù)生產(chǎn) bug 的代碼

場(chǎng)景設(shè)想

下面列舉一些可能你在工作中會(huì)經(jīng)常面對(duì)的場(chǎng)景

1. 組長(zhǎng)分配新需求下來，安排下周上線（假設(shè)是 1227 號(hào)），你看看當(dāng)前有沒有下周版本的分支？有的話很簡(jiǎn)單，checkout 下周分支（feature_app1.1.0_1227）來開發(fā)就行，沒有的話這時(shí)需要新建分支，從 develop 分支創(chuàng)建新的 feature 分支（feature_app1.1.0_1227）,然后將對(duì)應(yīng)的 pom.xml 版本號(hào)修改成 1.1.0-SNAPSHOT，注意命名，比如這里我用 feature 做前綴，你也可以自己設(shè)定一個(gè)規(guī)則。

2. 開發(fā)完 feature_app1.1.0_1227 需求，移交了測(cè)試，很遺憾，測(cè)試出現(xiàn)了 n 個(gè) bug，這時(shí)依舊在 feature_app1.1.0_1227 上修復(fù) bug。

3. 終于到了發(fā)版前一天，測(cè)試 MM 說 n 輪測(cè)試完了，沒問題，拉上線版本，再做一次回歸測(cè)試。這時(shí)，你就需要把 feature_app1.1.0_1227 分支合并到 develop 分支，然后從 develop 分支中創(chuàng)建新的分支 release_app1.1.0_1227，然后修改對(duì)應(yīng)的版本號(hào)為 1.1.0-RELEASE。

4. 到了發(fā)版日早上了，測(cè)試 MM 用了 release_app1.1.0_1227 版本測(cè)試了一番，又發(fā)現(xiàn)了一個(gè) bug。別慌，只要不是生產(chǎn)的 bug，都好解決。這時(shí)你要在 release_app1.1.0_1227 修復(fù) bug，切記不能在 feature_app1.1.0_1227 上修改，feature_app1.1.0_1227 分支已經(jīng)沒有多大作用了，只用來看代碼提交記錄。

5. 安安全全的到了晚上，開始發(fā)版了，發(fā)完版突然發(fā)現(xiàn)了有異常，定位問題后發(fā)現(xiàn)是有一行代碼寫錯(cuò)了，跟組長(zhǎng)確認(rèn)后，在 release_app1.1.0_1227 分支上做了修改，重新打包后發(fā)版，驗(yàn)證了一段時(shí)間，沒問題了。。。

6. 發(fā)版總算完成了，這時(shí)，別忘記把 release_app1.1.0_1227 版本合并到 develop 和 master 分支。還有一點(diǎn)很重要的，把 develop 分支代碼合并到 1227 以后的版本（如果已經(jīng)有1227 以后的版本的話）。注意：這個(gè)步驟合并代碼要謹(jǐn)慎，如果有別人的代碼合并沖突比較大，需要找那個(gè)開發(fā)的同事一起合并代碼。總算可以睡個(gè)好覺了。。。

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

8. 第二天，突然生產(chǎn)上一直報(bào) NullPointerException，定位發(fā)現(xiàn)是一行代碼沒有判空導(dǎo)致的，三番確認(rèn)，原來這個(gè)數(shù)據(jù)以前是不為空的，現(xiàn)在確實(shí)需要支持有些數(shù)據(jù)為空的，需要緊急修復(fù)這個(gè) bug，和組長(zhǎng)確認(rèn)之后，從 master 分支上拉了一個(gè) hotfix_app1.1.1_1228 分支代碼，修復(fù)了 NullPointerException，打包后上線，驗(yàn)證沒問題后，把 hotfix_app1.1.1_1228 分支合并到 develop 和 master 分支，并把 develop 分支合并到 1227 以后的版本。

好了，一大坨的文字描述了基于分支模型開發(fā)的過程。不同公司在應(yīng)用過程中可能會(huì)有些微小的不同，但是整體流程都是差不多的。比如有的公司可能會(huì)把 release 合并到 master 后，用 master 代碼發(fā)布到生產(chǎn)，發(fā)版當(dāng)時(shí)有異常，再從 master 分支上拉 hotfix 分支進(jìn)行修復(fù)。上面描述的步驟就不一樣了，發(fā)版時(shí)出現(xiàn)異常，直接在 release 上修復(fù)。這些小的差別就不用計(jì)較太多啦。

希望本文能夠讓你認(rèn)識(shí)到有這么一個(gè)標(biāo)準(zhǔn)的 Git 分支模型，在不管工作上還是學(xué)習(xí)上，在需要分支管理的時(shí)候，回憶起有這么一個(gè)圖，根據(jù)你的場(chǎng)景再應(yīng)用進(jìn)去，肯定會(huì)少走很多彎路。

公眾號(hào)原文： 成熟的 Git 分支模式