Git 代碼分支管理
作者:京東科技 周新智
一、引言
近日,IoT 研發團隊加入了不少新同學,對 git 分支的命名和管理方式有些許的模糊,分支的命名規范以及管理方式對項目的版本發布至關重要,為了解決實際開發過程中版本發布時代碼管理混亂、沖突等比較頭疼的問題,我們將在文中闡述如何更好的管理代碼分支。
二、總覽

從上圖可以看到主要包含下面幾個分支:
? master: 主分支,也稱為線上分支,主要用來版本發布。
? dev:日常開發分支,該分支正常保存了開發的最新代碼。
? release:release 分支可以認為是 master 分支的測試版。比如說某個新增功能開發完成、線上問題緊急修復完成,那么就將 feature/hotfix 分支合并到 release 分支,到了發布日期就合并到 master 分支,進行版本發布。
? feature:具體的功能開發分支。
? hotfix:線上 bug 修復分支。
三、主分支
主分支包括Master Branch、Release Branch、Dev Branch 三個分支:
1、Master Branch
用來進行版本發布,也就是當前線上運行的代碼分支
2、Release Branch
Release Branch 在我看來就是 Pre-Master。Release Branch 從 Master Branch 檢出,最終會合并到Master Branch,合并后 Master Branch上就是可以發布的代碼了。
所有新增功能的開發分支都是從 Dev Branch 檢出作為本地分支,以 feature-功能名-姓名首字母簡拼,當功能開發完畢的時候,將 feature Branch 合并到 Dev Branch,在測試或預生產環境進行部署,測試通過后,再將 feature Branch 合并到 Release Branch。
如果出現線上問題需要緊急修復,則從 Release Branch 檢出作為本地分支,以 hotfix-功能名-姓名首字母簡拼, 當問題修復完畢的時候,將hotfix Branch合并到 Dev Branch,在測試環境進行部署,測試通過后,再將 hotfix Branch 合并到 Release Branch,在預發環境再次驗證。
待所有的測試和準備工作做完之后,我們就可以將 release 分支合并到 master 分支上,并擇機進行線上發布。
3、Dev Branch
dev 就是我們的日常開發分支。
四、輔助分支
1、Feature分支
feature 分支用來開發具體的功能,一般 fork 自 Dev 分支,以 feature-功能名-姓名首字母簡拼 進行命名,最終合并到 Dev 、Release分支。比如我們要在下一個版本增加功能1、功能2、功能3。那么我們就可以起三個feature 分支:feature-1-zxz,feature-2-qxh,feature-3-sq。(feature 分支命名最好能夠自解釋,1、2、3 這并不是一種好的命名)隨著我們開發,功能1和功能2都被完成了,而功能3因為某些原因完成不了,那么最終 feature-1-zxz 和 feature-2-qxh 分支將被合并到 Dev 分支,而 feature-3-sq 分支將延期繼續進行本地開發工作,功能1和功能2測試完沒有問題后,將 feature1 和 feature2 分支將被合并到 Release 分支,最終將 Release 分支合并到 Master 分支。
2、Hotfix 分支
顧名思義,hotfix 分支用來修復線上 bug。當線上代碼出現 bug 時,我們基于 Release 分支開一個 hotfix 分支,以 hotfix-功能名-姓名首字母簡拼(例如:hotfix-model-base-zxz),修復 bug 之后再將 hotfix 分支合并到 Release 分支,同時 Dev 分支作為最新最全的代碼分支,hotfix 分支也需要合并到 Dev 分支上去,同時在不同分支對應的不同環境進行bug回歸驗證,最終將 Release 分支合并到 Master 分支,進行線上發布即可。
五、注意事項
1、 Feature 分支、Hotfix 分支合并到 Dev 分支,測試通過后,需再合并到 Release 分支,這時候就要求代碼合并時需清楚的知道此代碼是否已經經過驗證。
2、 Dev、Release、Master分支的同步
Release 分支合并到 Master 分支后,若Dev分支無正在測試的功能,建議定時將 Dev、Release、Master 分支進行代碼同步。
通過以上分支管理,我們就可以輕松做到:團隊成員之間功能并行開發、功能選擇性發布、版本發布、線上問題緊急功能開發、緊急問題修復等。
浙公網安備 33010602011771號