產(chǎn)品開(kāi)發(fā)中的一種Git分支工作方法
一、前言
Git作為版本控制管理工具中的優(yōu)秀代表，其分支管理功能使得團(tuán)隊(duì)協(xié)同開(kāi)發(fā)成為一件非常簡(jiǎn)單的事情。本文介紹一種產(chǎn)品開(kāi)發(fā)中的Git分支工作方法，以供探討。
二、產(chǎn)品的軟件版本號(hào)定義
軟件版本號(hào)定義，分四項(xiàng)：主版本號(hào).子版本號(hào).修訂號(hào).Build號(hào)，如：V1.3.2.123軟件hotfix版本號(hào)定義，分四項(xiàng)：主版本號(hào).子版本號(hào).修訂號(hào).修補(bǔ)號(hào)，如：V1.3.2.125
版本號(hào) | 說(shuō)明 | 備注 |
主版本號(hào) | 系統(tǒng)業(yè)務(wù)重構(gòu)或架構(gòu)重構(gòu)時(shí)增加；重大功能或方向改變時(shí)增加；大范圍不兼容之前的接口時(shí)增加。 | |
子版本號(hào) | 增加新的業(yè)務(wù)功能時(shí)增加。 | |
修訂號(hào) | 有改動(dòng)就增加。 | 從0開(kāi)始 |
修補(bǔ)號(hào) | hostfix版本號(hào)基于所修復(fù)的版本的Build號(hào)，取發(fā)布版本的最大的Build號(hào)往上增加如果修復(fù)基于V1.3.2.1，則hotfix版本為V1.3.2.2如果當(dāng)前發(fā)布版本的Build版本是V1.3.2.101，當(dāng)前最大Build號(hào)為105，則修補(bǔ)版本號(hào)為V1.3.2.106 | 從1開(kāi)始 |
Build號(hào) | 編譯號(hào)，有編譯就增加。 | 從1開(kāi)始 |
三、Git分支命名
1.基本分支
分支命名 | 說(shuō)明 | 生命周期 |
master | 記錄上線版本的迭代，該分支代碼與線上代碼是完全一致的主分支 | 項(xiàng)目存在期間存續(xù)，項(xiàng)目下線之后歸檔 |
dev | 記錄開(kāi)發(fā)代碼活動(dòng)歷史 | 同master |
test | 記錄測(cè)試活動(dòng)歷史 | 同master |
feature-(ver)-(name) | 屬于開(kāi)發(fā)個(gè)人的代碼活動(dòng)歷史記錄，如David正在開(kāi)發(fā)1.0.1版本，則分支名為：feature-v1.0.1-david | 版本開(kāi)始開(kāi)發(fā)至版本發(fā)布，版本發(fā)布后結(jié)束 |
2.擴(kuò)展分支
分支命名 | 說(shuō)明 | 生命周期 |
hostfix-(ver) | 線上版本的緊急修復(fù)代碼分支，開(kāi)發(fā)與測(cè)試都采用同一分支 | 版本開(kāi)始開(kāi)發(fā)至版本發(fā)布 |
dev-(company) | 記錄針對(duì)特定需求的定制化版本的開(kāi)發(fā)代碼活動(dòng)歷史 | 項(xiàng)目存在期間存續(xù)，項(xiàng)目下線之后歸檔 |
test-(company) | 記錄針對(duì)特定需求的定制化版本的測(cè)試代碼活動(dòng)歷史 | 同dev-(company) |
feature-(company)-v1.0.2-(name) | 屬于開(kāi)發(fā)個(gè)人的定制化版本的開(kāi)發(fā)代碼活動(dòng)歷史記錄，如David正在開(kāi)發(fā)的定制化阿里公司的1.0.1版本，則分支名為：feature-ali-v1.0.1-david | 版本開(kāi)始開(kāi)發(fā)至版本發(fā)布，版本發(fā)布后結(jié)束 |
dev-v1.0.2 | 多分支并發(fā)開(kāi)發(fā)時(shí)，記錄特定版本的開(kāi)發(fā)代碼活動(dòng)歷史 | 版本開(kāi)始開(kāi)發(fā)至版本發(fā)布 |
test-v1.0.2 | 多分支并發(fā)開(kāi)發(fā)時(shí)，記錄特定版本的測(cè)試代碼活動(dòng)歷史 | 版本開(kāi)始開(kāi)發(fā)至版本發(fā)布 |
3、tags
tag命名 | 說(shuō)明 | 生命周期 |
tag-v(ver) | 僅針對(duì)發(fā)布版本打tag，如：tag-v1.0.0.1 | 項(xiàng)目存在期間存續(xù)，項(xiàng)目下線之后歸檔 |
四、Git分支工作規(guī)范
1.分支工作基本原則
master：系統(tǒng)版本的準(zhǔn)線，版本通過(guò)測(cè)試并處于可發(fā)布狀態(tài)時(shí)，才可合并入master，一直維持可構(gòu)建狀態(tài)。
dev*：協(xié)同開(kāi)發(fā)分支，不可直接提交，僅可通過(guò)其他分支合并進(jìn)入。
test*：測(cè)試分支，不可直接提交，僅可通過(guò)dev*分支合并進(jìn)入。
feature*：個(gè)人開(kāi)發(fā)分支，個(gè)人開(kāi)發(fā)完成需要合并入dev分之前，先push至遠(yuǎn)程feature分支。
2.一般項(xiàng)目開(kāi)發(fā)
工作流程如上圖：
- 項(xiàng)目負(fù)責(zé)人從master的基線check out，初始化dev分支；
- 開(kāi)發(fā)者從dev分支check out，建立本地個(gè)人開(kāi)發(fā)分支feature*；
- 開(kāi)發(fā)者完成功能開(kāi)發(fā)后，commit個(gè)人feature*分支，并push至遠(yuǎn)程個(gè)人feature*分支；
- 開(kāi)發(fā)者在gitlab上提交個(gè)人的代碼和并請(qǐng)求至dev分支；
- 代碼審查人負(fù)責(zé)代碼審查，合并合理代碼；
- 代碼提測(cè)時(shí)，開(kāi)發(fā)負(fù)責(zé)人提交dev分支到test的合并請(qǐng)求；
- 項(xiàng)目負(fù)責(zé)人合并dev分支至test分支；
- 版本測(cè)試完成后，開(kāi)發(fā)負(fù)責(zé)人提交test分支至master分支的合并請(qǐng)求；
- 項(xiàng)目負(fù)責(zé)人合并代碼至master；
- 項(xiàng)目負(fù)責(zé)人以當(dāng)前代碼為基線，在master分支上tag當(dāng)前版本號(hào)。
3.hostfix版本開(kāi)發(fā)
hostfix為緊急修復(fù)的版本，不同于正常需求的版本流程。工作流程如下圖。
4.定制化版本開(kāi)發(fā)
定制化版本出現(xiàn)在給某些特定用戶提供特殊定制的功能，而又與主干分支存在不同業(yè)務(wù)邏輯的情況下。工作流程如下圖。
5.多版本并行
版本測(cè)試的時(shí)候，可能存在開(kāi)發(fā)團(tuán)隊(duì)眼巴巴等待測(cè)試反饋bug的時(shí)候。配合默契的多版本并行開(kāi)發(fā)，可以合理利用時(shí)間，加速版本迭代。工作流程如下圖。
