摘要：一介紹本文介紹一種多人參與開發(fā)時的分支管理模型，在團隊項目中成功實踐。開發(fā)新的功能某先從分支出分支，命名為。建議請勿在周五發(fā)布任何正式環(huán)境分支，以免出現(xiàn)問題六分支命名的建議分支以它類型名字命名。如修復連接數(shù)泄漏的分支，可命名為。

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

一般來說，服務器端分以下幾種運行、部署環(huán)境：

staging：用于開發(fā)功能時給?RD?測試用，代碼、數(shù)據(jù)庫都是測試環(huán)境的。

preview：用于代碼部署到生產(chǎn)環(huán)境前的測試，代碼是準生產(chǎn)版本，數(shù)據(jù)庫是生產(chǎn)環(huán)境的。

production：生產(chǎn)環(huán)境，代碼、數(shù)據(jù)庫都是生產(chǎn)環(huán)境的。

以上環(huán)境的代碼穩(wěn)定版依次提高。

為配合以上幾種部署環(huán)境，代碼庫分以下幾種類型的分支：

staging?分支：用于 staging 環(huán)境的部署。

master?分支：GIT 的默認分支，提供最新、穩(wěn)定的代碼。

preview?分支：用于 preview 環(huán)境的部署。

release?分支：用于 production 環(huán)境的部署，保持代碼隨時可發(fā)布到生產(chǎn)環(huán)境。

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

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

feature 分支：以 feature_xxx 命名，其中，xxx 表示對**子功能**的簡單描述。
一個功能會拆成若干個子功能，每個 RD 開發(fā)?1 個子功能。dev 分支與 feature 分支的區(qū)別：
一個新功能通常需要多個 RD 參與開發(fā)。RD 在各自的 feature 分支提交代碼。存在一種情況，RD B 的代碼
依賴 RD A，而這個時候兩個人寫的代碼都不穩(wěn)定，不適合往 master 分支合并。此時，RD A 將自己的代碼
先合入 dev 分支，RD B 基于 dev 分支進行開發(fā)。

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

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

綜上，一般情況，我們一共會用到以下幾種分支： staging、master、preview、release、dev、feature、bugfix、hotfix 。

?

默認存在，master 分支上保持最新的、穩(wěn)定的代碼。
從以下分支合并（merged from）：
dev、bugfix、hotfix

從以下分支合并（merged from）：
master
合入以下分支：
一旦拉出，不再合入其它分支
說明：
preview 分支用于代碼部署到生產(chǎn)環(huán)境前的預發(fā)布，用于正式上線前的最后一次測試。master 分支的代碼部署到生產(chǎn)環(huán)境前，
先用 merge （發(fā) merge request 或用 git merge 命令，下同）把代碼合入 preview 分支。

從以下分支合并（merged from）：
master
合入以下分支：
一旦拉出，不再合入其它分支
說明：
preview 分支的代碼在預生產(chǎn)環(huán)境測試通過后，master 分支上、合入 preview 分支的結點，往 release 分支 merge 一次。

從以下分支合并（merged from）：
feature
合入以下分支：
一旦拉出，不再合入其它分支
?
說明：
?
staging 分支的代碼給 RD 測試功能用。RD 在 feature 開發(fā)完子功能后，把代碼提交到 feature 分支，再把 feature 分支合到 staging 分支。最后在 xbox 上部署 staging 環(huán)境，進行測試。

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

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

說明：
feature 分支用于 RD 個人提交代碼。開發(fā)新功能時，每個 RD 從 dev 分支 fork 出自己的 feature 分支，不同 RD 在遠程代碼倉庫不共享?feature 分支。當代碼可測試時，先提交到 feature 分支，再 merge 到 staging 分支、發(fā)布、測試。測試通過后，merge 到 dev 分支。如果另外一個 RD 需要依賴你的代碼，他需要先將自己 feature 分支 rebase （用 git rebase 命令）到最新的 dev 分支（包含你的代碼），然后進行開發(fā)。

派生自以下分支（forked from）：
master
合入以下分支：
staging、master
說明：
bugfix 分支用于修復常規(guī)、不緊急的 bug。RD 開始修復 bug 時，從 master 分支 fork 出 bugfix 分支。提交修復代碼后，把 bugfix 分支 merge 到 staging，在 staging 環(huán)境發(fā)布、測試。測試通過后，再把 bugfix 分支 merge 到 master，然后刪除。

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

說明：
hotfix 分支用于修復生產(chǎn)環(huán)境的、緊急的 bug。RD 開始修復緊急 bug 時，從 release 分支 fork 出 hotfix 分支。提交修復代碼后，把 hotfix 分支 merge 到 staging，在 staging 環(huán)境發(fā)布、測試。在 staging 測試通過后，再把 hotfix 分支 merge 到 preview，在 preview 環(huán)境進行測試。測試也通過后，再 merge 到 master、release 分支。

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

1、某 RD 先從 master 分支 fork 出 dev 分支，命名為 dev_xxx 。
2、參與開發(fā)這個功能的 RD 基于 dev_xxx 分支 fork 出 feature_xxx_RDA，feature_xxx_RDB 等分支。
3、各 RD 在自己的 feature 分支開發(fā)子功能。
4、RD A 在自己的分支 feature_xxx_RDA 上提交了幾個工具類，這些類會給其他 RD 用。他把 feature_xxx_RDA push（用 git push 命令）到遠程倉庫，再 merge 到 staging，在 staging 環(huán)境發(fā)布、測試。如果測試發(fā)現(xiàn)問題，他再提交一個 commit 到?feature_xxx_RDA 分支，然后 merge 到 staging，再發(fā)布、測試。測試通過后，他把?feature_xxx_RDA merge 到 dev_xxx 分>支，然后繼續(xù)開發(fā)其它功能。
5、RD B 的工作依賴 RD A 開發(fā)的工具類。他把?feature_xxx_RDB rebase 到 最新的 dev_xxx 分支，然后進行開發(fā)。
6、所有 RD 開發(fā)完后，某 RD 再把 dev_xxx 分支 merge 到 master 分支，然后刪除 dev_xxx 分支。
某 RD 再把 master 分支 merge 到 preview 分支。
7、在 preview 測試通過后，再把 master 分支 merge 到 release 分支，然后發(fā)布到生產(chǎn)環(huán)境。

1、某 RD 領到一個 bug。開始修復時，他從 master 分支 fork 出 bugfix 分支，命名為 bugfix_xxx 。
2、RD 在 bugfix_xxx 分支上提交修復代碼，自己測試通過后，merge 到 staging，并且在 staging 
環(huán)境發(fā)布、測試。如果測試發(fā)現(xiàn)問題，他再提交一個 commit 到 bugfix_xxx 分支，然后再 merge 
到 staging，再發(fā)布、測試。直到測試完全通過，他把 bugfix_xxx merge 到 master 分支，然后刪除 bugfix_xxx 分支。
3、因為是常規(guī) bug，他不需要馬上把修復的代碼部署到生產(chǎn)環(huán)境。等待下一次發(fā)布周期即可。

緊急 bug 是指如果不馬上修復，會造成重大損失的 bug。操作步驟如下：

1、某 RD 領到一個緊急?bug。開始修復時，他從 release 分支 fork 出 hotfix 分支，命名為 hotfix_xxx。
2、RD 在 hotfix_xxx 分支進行修復。提交代碼后，他把 hotfix_xxx merge 到 staging，并且在 staging 環(huán)境發(fā)布、測試。如果測試發(fā)現(xiàn)問題，他再提交一個 commit 到 hotfix_xxx 分支，然后再 merge 到 staging，再發(fā)布、測試。直到測試完全通過，他把 hotfix_xxx merge 到 preview 分支，在 preview 環(huán)境測試。如果測試發(fā)現(xiàn)問題，繼續(xù)在 hotfix_xxx 分支提交修復代碼，再 merge 到 staging 進行測試。
3、preview 環(huán)境測試通過后，RD 把 hotfix_xxx merge 到 release 分支。上線，在生產(chǎn)環(huán)境觀察 bug 是否修復。
4、如果生產(chǎn)環(huán)境還有問題，繼續(xù)在 hotfix_xxx 修復，然后在 staging、preview 測試，測試通過再重新上線。這種情況應該盡可能**避免**，保證一次上線修復成功。
5、生產(chǎn)環(huán)境驗證沒問題后，RD 把 hotfix_xxx merge 到 master，然后刪除 hot_xxx 分支。

建議：請勿在周五發(fā)布任何正式環(huán)境分支，以免出現(xiàn)問題.

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

反例

1、 不包含任何前綴
2、 只包含前綴、時間戳
3、 只包含前綴、姓名
4、 其它可讀性低的命名

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

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

RD: Research and Development engineer，研發(fā)工程師