Git在公司內(nèi)部的使用規(guī)范
1.版本定義
版本號(hào)使用x.x.x.x進(jìn)行定義.
- 第一個(gè)x代表大版本只有在項(xiàng)目有重大變更時(shí)更新；
- 第二個(gè)x保留；
- 第三個(gè)x代表常規(guī)版本有新求會(huì)更新；
- 第四個(gè)x代表緊急Bug修正；
一個(gè)常見的版本號(hào)類似于：0.0.10.11
2.系統(tǒng)開發(fā)環(huán)境
| 簡(jiǎn)稱 |
全稱 |
作用 |
| DEV |
Development environment |
用于開發(fā)者調(diào)試使用 |
| FAT |
Feature Acceptance Test environment |
功能驗(yàn)收測(cè)試環(huán)境，用于測(cè)試環(huán)境下的軟件測(cè)試者測(cè)試使用 |
| UAT |
User Acceptance Test environment |
用戶驗(yàn)收測(cè)試環(huán)境，用于生產(chǎn)環(huán)境下的軟件測(cè)試者測(cè)試使用 |
| PRO |
Production environment |
生產(chǎn)環(huán)境 |
3. 分支定義
| 分支 |
名稱 |
作用 |
| master |
主分支 |
用于生產(chǎn)部署，最新穩(wěn)定版本，一般由 release 或 hotfix 分支合并，任何情況下不允許直接在 master 分支上修改代碼。 |
| release |
預(yù)上線分支 |
預(yù)上線分支，是develop與master之間的一個(gè)緩沖，始終保持與 master 分支一致，一般由 develop 或 hotfix 分支合并，不建議直接在 release 分支上直接修改代碼。（UAT） |
| hotfix |
緊急修復(fù)分支 |
緊急分支，名規(guī)則為 hotfix- 開頭，從master生成，bug修正后自動(dòng)合并到master和develop并且生成tag； |
| develop |
測(cè)試分支 |
功能驗(yàn)收測(cè)試環(huán)境，用于測(cè)試環(huán)境下的軟件測(cè)試者測(cè)試使用，可根據(jù)需求大小程度確定是由 feature 分支合并，還是直接在上面開發(fā)。，F(xiàn)AT，如果開發(fā)工時(shí) < 1d，直接在 develop 開發(fā)，如果開發(fā)工時(shí) > 1d，那就需要?jiǎng)?chuàng)建分支，在分支上開發(fā)。 |
| feature |
需求開發(fā)分支 |
用于開發(fā)新需求和需要較長(zhǎng)時(shí)間的BUG修改，(正式環(huán)境) 測(cè)試通過后，研發(fā)人員需要?jiǎng)h除 feature- 分支。 |
4.Commit 日志規(guī)范
提交信息一定要認(rèn)真填寫！
建議參考規(guī)范：(scope)：
比如：fix(首頁(yè)模塊)：修復(fù)彈窗 JS Bug。
type 表示 動(dòng)作類型，可分為：
fix：修復(fù) xxx Bug
feat：新增 xxx 功能
test：調(diào)試 xxx 功能
style：變更 xxx 代碼格式或注釋
docs：變更 xxx 文檔
refactor：重構(gòu) xxx 功能或方法
scope 表示 影響范圍，可分為：模塊、類庫(kù)、方法等。
subject 表示 簡(jiǎn)短描述，最好不要超過 60 個(gè)字，如果有相關(guān) Bug 的 Jira 號(hào)，建議在描述中加上。
5.開發(fā)工作流程：
git flow feature start xxxxx（開始新需求）
在feature/xxxxx分支下進(jìn)行開發(fā)
git flow feature finish xxxxx（開發(fā)完成后等待研發(fā)經(jīng)理確認(rèn)可以完成時(shí)執(zhí)行）
git push origin develop（發(fā)布develop分支）
每天工程師都需要git pull origin develop來(lái)更新develop分支，然后將develop分支合并到你正在開發(fā)得feature/xxxxx分支上來(lái)保持代碼最新
切記不能直接在develop上進(jìn)行開發(fā)
5.1.常規(guī)分支debug流程：
- 由研發(fā)經(jīng)理通知相關(guān)工程師release版本x.x
- git fetch
- git checkout -b release/x.x origin/release/x.x（拉回release版本）
- git pull release/x.x（更新該分支）
- 修改測(cè)試中發(fā)現(xiàn)的BUG
- git push origin release/vx.x（修改完后提交分支）
- 循環(huán)4-5
5.2.緊急debug流程：
- 由研發(fā)經(jīng)理通知相關(guān)工程師hotfix分支名稱x.x.x
- git fetch
- git checkout -b hotfix/x.x.x origin/hotfix/x.x.x（拉回hotfix分支）
- git pull hfx.x（更新hotfix分支）
- 在熱修復(fù)分支下修改bug
- git push origin hfx.x（修改完成，提交分支）
在日常工作中不能修改master分支下得代碼
5.3.研發(fā)經(jīng)理：
開發(fā)和DEBUG流程同工程師流程
5.3.1.常規(guī)分支debug流程：
- git pull origin develop（更新develop分支為最新）
- git checkout develop（切換到develop分支）
- git flow release start x.x（生成一個(gè)release分支）
- 通知測(cè)試和相關(guān)得工程師分支名稱
- git pull origin release/x.x（最終測(cè)試完成后拉回分支最新代碼）
- git flow release finish x.x（最終修改和測(cè)試完成后，結(jié)束release版本以供發(fā)布）
- git push origin develo (發(fā)布最新的develop)
- git push origin master（發(fā)布最終得master分支）
5.3.2緊急debug流程：
- git pull origin master（更新master分支為最新）
- git checkout master（切換到master分支）
- git flow hotfix start x.x.x（生成一個(gè)hotfix分支）
- 通知相關(guān)得工程師和測(cè)試人員hotfix分支名稱
- git pull origin hotfix/x.x.x（最終測(cè)試完成后拉回分支最新代碼）
- git flow hot fix finish x.x.x（最終修改和測(cè)試完成后，結(jié)束hot fix以供發(fā)布）
- git push origin master（發(fā)布最終得master分支）
在全部的流程中，工程師必須維護(hù)自己的feature分支保證代碼最新，減少合并時(shí)的沖突。
研發(fā)經(jīng)理必須維護(hù)release分支，將最新的hotfix都合并進(jìn)去，保證代碼最新，減少合并時(shí)的沖突。
在提交代碼時(shí)還要注意判斷對(duì)代碼的修改是否是自己的，多用diff工具，多查看log，防止代碼回溯
|
