開發過程當中的git分支管理

1、介紹

本文介紹一種多人蔘與開發時的 GIT 分支管理模型，在團隊項目中成功實踐。使用的是gitlab來作代碼管理與權限控制。

2、服務器部署環境

通常來講，服務器端分如下幾種運行、部署環境：

• staging：用於開發功能時給 RD 測試用，代碼、數據庫都是測試環境的。

• preview：用於代碼部署到生產環境前的測試，代碼是準生產版本，數據庫是生產環境的。

• production：生產環境，代碼、數據庫都是生產環境的。

以上環境的代碼穩定版依次提升。

3、分支種類

爲配合以上幾種部署環境，代碼庫分如下幾種類型的分支：

• staging 分支：用於 staging 環境的部署。

• master 分支：GIT 的默認分支，提供最新、穩定的代碼。

• preview 分支：用於 preview 環境的部署。

• release 分支：用於 production 環境的部署，保持代碼隨時可發佈到生產環境。

以上幾個分支會永久存在於代碼庫中，在開發功能、修復 BUG 的過程當中，還會用到幾種分支。
開發新功能時會用到的：

dev 分支：以 dev_xxx 命名。xxx 表示**功能**的簡單描述。

feature 分支：以 feature_xxx 命名，其中，xxx 表示對**子功能**的簡單描述。
一個功能會拆成若干個子功能，每一個 RD 開發 1 個子功能。dev 分支與 feature 分支的區別：
一個新功能一般須要多個 RD 參與開發。RD 在各自的 feature 分支提交代碼。存在一種狀況，RD B 的代碼
依賴 RD A，而這個時候兩我的寫的代碼都不穩定，不適合往 master 分支合併。此時，RD A 將本身的代碼
先合入 dev 分支，RD B 基於 dev 分支進行開發。

修復常規 bug 時會用到的：
bugfix：以 bugfix_xxx 命名。xxx 表示 bug 的簡單描述。

修復緊急 bug 時會用到的：
hotfix：以 hotfix_xxx 命名。xxx 表示 bug 的簡單描述。

綜上，通常狀況，咱們一共會用到如下幾種分支： staging、master、preview、release、dev、feature、bugfix、hotfix 。

 

4、分支的生命週期

示意圖

master 分支

默認存在，master 分支上保持最新的、穩定的代碼。
從如下分支合併（merged from）：
dev、bugfix、hotfix

preview 分支

從如下分支合併（merged from）：
master
合入如下分支：
一旦拉出，再也不合入其它分支
說明：
preview 分支用於代碼部署到生產環境前的預發佈，用於正式上線前的最後一次測試。master 分支的代碼部署到生產環境前，
先用 merge （發 merge request 或用 git merge 命令，下同）把代碼合入 preview 分支。

release 分支

從如下分支合併（merged from）：
master
合入如下分支：
一旦拉出，再也不合入其它分支
說明：
preview 分支的代碼在預生產環境測試經過後，master 分支上、合入 preview 分支的結點，往 release 分支 merge 一次。

staging 分支

從如下分支合併（merged from）：
feature
合入如下分支：
一旦拉出，再也不合入其它分支
 
說明：
 
staging 分支的代碼給 RD 測試功能用。RD 在 feature 開發完子功能後，把代碼提交到 feature 分支，再把 feature 分支合到 staging 分支。最後在 xbox 上部署 staging 環境，進行測試。

dev 分支

 派生自如下分支（forked from）： master
合入如下分支： master
說明：
dev 分支用於多人開發同一個功能時提交代碼。它的存在時間跟新功能開發的時間相同。新功能開始開發時，它從 master 分支 fork 出來；新功能開發結束時，它被合入 master 分支，而後刪除。

feature 分支

派生自如下分支（forked from）：
dev
合入如下分支：
staging、dev

說明：
feature 分支用於 RD 我的提交代碼。開發新功能時，每一個 RD 從 dev 分支 fork 出本身的 feature 分支，不一樣 RD 在遠程代碼倉庫不共享 feature 分支。當代碼可測試時，先提交到 feature 分支，再 merge 到 staging 分支、發佈、測試。測試經過後，merge 到 dev 分支。若是另一個 RD 須要依賴你的代碼，他須要先將本身 feature 分支 rebase （用 git rebase 命令）到最新的 dev 分支（包含你的代碼），而後進行開發。

bugfix 分支

派生自如下分支（forked from）：
master
合入如下分支：
staging、master

說明：
bugfix 分支用於修復常規、不緊急的 bug。RD 開始修復 bug 時，從 master 分支 fork 出 bugfix 分支。提交修復代碼後，把 bugfix 分支 merge 到 staging，在 staging 環境發佈、測試。測試經過後，再把 bugfix 分支 merge 到 master，而後刪除。

hotfix 分支

派生自（forked from）：release
合入如下分支：staging、master、preview、release

說明：
hotfix 分支用於修復生產環境的、緊急的 bug。RD 開始修復緊急 bug 時，從 release 分支 fork 出 hotfix 分支。提交修復代碼後，把 hotfix 分支 merge 到 staging，在 staging 環境發佈、測試。在 staging 測試經過後，再把 hotfix 分支 merge 到 preview，在 preview 環境進行測試。測試也經過後，再 merge 到 master、release 分支。

5、典型場景舉例

下面舉例一些常見場景，以及分支的操做步驟。

開發新的功能

一、某 RD 先從 master 分支 fork 出 dev 分支，命名爲 dev_xxx 。
二、參與開發這個功能的 RD 基於 dev_xxx 分支 fork 出 feature_xxx_RDA，feature_xxx_RDB 等分支。
三、各 RD 在本身的 feature 分支開發子功能。
四、RD A 在本身的分支 feature_xxx_RDA 上提交了幾個工具類，這些類會給其餘 RD 用。他把 feature_xxx_RDA push（用 git push 命令）到遠程倉庫，再 merge 到 staging，在 staging 環境發佈、測試。若是測試發現問題，他再提交一個 commit 到 feature_xxx_RDA 分支，而後 merge 到 staging，再發布、測試。測試經過後，他把 feature_xxx_RDA merge 到 dev_xxx 分>支，而後繼續開發其它功能。
五、RD B 的工做依賴 RD A 開發的工具類。他把 feature_xxx_RDB rebase 到 最新的 dev_xxx 分支，而後進行開發。
六、全部 RD 開發完後，某 RD 再把 dev_xxx 分支 merge 到 master 分支，而後刪除 dev_xxx 分支。
某 RD 再把 master 分支 merge 到 preview 分支。
七、在 preview 測試經過後，再把 master 分支 merge 到 release 分支，而後發佈到生產環境。

修復常規 bug

一、某 RD 領到一個 bug。開始修復時，他從 master 分支 fork 出 bugfix 分支，命名爲 bugfix_xxx 。
二、RD 在 bugfix_xxx 分支上提交修復代碼，本身測試經過後，merge 到 staging，而且在 staging 
環境發佈、測試。若是測試發現問題，他再提交一個 commit 到 bugfix_xxx 分支，而後再 merge 
到 staging，再發布、測試。直到測試徹底經過，他把 bugfix_xxx merge 到 master 分支，而後刪除 bugfix_xxx 分支。
三、由於是常規 bug，他不須要立刻把修復的代碼部署到生產環境。等待下一次發佈週期便可。

修復線上緊急 bug

緊急 bug 是指若是不立刻修復，會形成重大損失的 bug。操做步驟以下：

一、某 RD 領到一個緊急 bug。開始修復時，他從 release 分支 fork 出 hotfix 分支，命名爲 hotfix_xxx。
二、RD 在 hotfix_xxx 分支進行修復。提交代碼後，他把 hotfix_xxx merge 到 staging，而且在 staging 環境發佈、測試。若是測試發現問題，他再提交一個 commit 到 hotfix_xxx 分支，而後再 merge 到 staging，再發布、測試。直到測試徹底經過，他把 hotfix_xxx merge 到 preview 分支，在 preview 環境測試。若是測試發現問題，繼續在 hotfix_xxx 分支提交修復代碼，再 merge 到 staging 進行測試。
三、preview 環境測試經過後，RD 把 hotfix_xxx merge 到 release 分支。上線，在生產環境觀察 bug 是否修復。
四、若是生產環境還有問題，繼續在 hotfix_xxx 修復，而後在 staging、preview 測試，測試經過再從新上線。這種狀況應該儘量**避免**，保證一次上線修復成功。
五、生產環境驗證沒問題後，RD 把 hotfix_xxx merge 到 master，而後刪除 hot_xxx 分支。

建議：請勿在週五發佈任何正式環境分支，以避免出現問題.

6、分支命名的建議

master、release、staging、preview 分支以它類型名字命名。
推薦的命名方式
對 dev 分支，建議以 dev_xxx_時間戳，其中，xxx 表示功能的英文簡單描述，多個分詞間用下劃線分隔，時間戳用 yyyyMMdd 格式。如「保險禮品後臺」功能的開發分支，可命名爲 dev_ins_gift_20170329。
對 feature、bugfix、hotfix 分支，建議以 前綴_xxx_姓名 命名，其中前綴指 feature、bugfix、hotfix，xxx 表示功能的簡單描述，姓名是負責開發功能的 RD 名字拼音。如修復鏈接數泄漏 bug 的分支，可命名爲 bugfix_fix_conn_leak_zhangsan 。

反例

一、 不包含任何前綴
二、 只包含前綴、時間戳
三、 只包含前綴、姓名
四、 其它可讀性低的命名

7、參考

https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/

http://nvie.com/posts/a-succe...

附錄 名詞解釋

RD: Research and Development engineer，研發工程師