Git在公司內部的使用規範

時間 2020-05-16

標籤 git 公司內部使用規範欄目 Git 简体版

原文原文鏈接

Git在公司內部的使用規範

1.版本定義

版本號使用x.x.x.x進行定義.git

第一個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。fetch

type 表示動做類型，可分爲：debug

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，防止代碼回溯