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 日志規范
提交信息一定要認真填寫!
建議參考規范:(scope):
比如: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流程:
5.2.緊急debug流程:
在日常工作中不能修改master分支下得代碼
5.3.研發經理:
開發和DEBUG流程同工程師流程
5.3.1.常規分支debug流程:
5.3.2緊急debug流程:
在全部的流程中,工程師必須維護自己的feature分支保證代碼最新,減少合并時的沖突。
研發經理必須維護release分支,將最新的hotfix都合并進去,保證代碼最新,減少合并時的沖突。
在提交代碼時還要注意判斷對代碼的修改是否是自己的,多用diff工具,多查看log,防止代碼回溯
總結
以上是生活随笔為你收集整理的Git在公司内部的使用规范的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Curl http_code 状态码
- 下一篇: 钢材整车运输找卡车易行吗?运输有保障不?