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