本規范可以作為公司或團隊的規范文檔，歡迎大家提供意見來一起補充完善與轉發。
1. 規范背景與目的
團隊開發中，遵循一個合理、清晰的Git使用流程，是非常重要的，否則每個人都提交一堆雜亂無章的commit，項目很快就會變得難以協調和維護。規范的commit注釋也能馬上看到這行代碼是哪個需求提交的。以下所有規范會按照【強制】、【建議】兩個級別進行標注，遵守優先級從高到低。
2. 規范說明
2.1 分支
- 【強制】每次開發新功能，都必須從最新的master分支(或其他依賴分支)上新建一個單獨的分支，產品與技術需求以“需求編號”命名，比如：feature-1201，bug修復可以fix/[user]-[yyyyMMdd]命名，user可以是開發人員名稱簡寫。
- 【強制】在需求分支提merge request前，必須先pull master代碼，防止代碼沖突。
- 【強制】在pull其他分支代碼時，對不確定的沖突代碼必須先與其開發人員確認，防止合并代碼時丟失而導致線上問題。
- 【建議】管理員對分支的merge request代碼進行Review。
2.2 注釋
- 【強制】git commit必須包含注釋。
- 【建議】可以參考業界通用的git提交規范 commitizen，制定適合自己的提交規范。比如可以參考如下的格式規范。
注釋格式：type(scope) : subject(分支號) 。其中
type（必須）: commit 的類別，只允許使用下面幾個標識：
feat : 新功能
fix : 修復bug
docs : 文檔改變
refactor : 某個已有功能重構
perf : 性能優化
test : 增加測試
revert : 撤銷上一次的 commit
scope（可選） : 用于說明 commit 影響的范圍，比如數據層、控制層、視圖層等等，視項目的不同而不同。
subject（必須） : commit 的簡短描述，不超過50個字符，內容不要是'fix'、'update'、'commit'等這些無用的描述。
分支號（必須）：此次提交的分支號(如feature-878、fix/mary-20200315)，用來查看代碼是哪個需求修改，方便后期維護。
如下圖一個Git注釋提交記錄示例：
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
