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