提交代碼時的commit內容不明確不完整。當回溯代碼的時候，很難通過commit內容定位歷史記錄，只能一條一條查看，找不到就要去問歷史參與開發的其他同事，溝通成本太高了。

為了提搞回溯的效率，方便定位問題，定義如下commit規範：

<type>: 【<scope>】<subject>

每個提交都必須使用類型字段前綴，它由一個名詞組成，諸如 feat 或 fix ，其後接一個作用域字段，以及一個必要的冒號（英文半角）和空格。

type：提交類型；
scope：修改文件影響的範圍，影響到全局，可以加個 global。如果影響的是某個目錄或某個功能，可以加上該目錄的路徑，或者對應的功能名稱（比如字體，layout佈局，utils，router，工作台，市場，卡片編輯，組裝卡片，PPT，管理後台，團隊權限等）；
subject：用一句話清楚的描述這次提交做了什麼，涉及到難發現/復現的bug（也可以加上描述為什麼修改, 做了什麼樣的修改, 以及開發的思路等）；

commit type類型：

feat：新功能

fix：修補bug

docs：:文檔修改

refactor：代碼重構或性能優化（比如重構：既不是新增功能，也不是修改bug的代碼變動；perf: 在不影響代碼內部行為的前提下，對程序性能進行優化；style：代碼格式修改，不影響代碼運行的變動，不影響代碼邏輯）

chore：其他雜項（比如構建過程或輔助工具；deps: 升級依賴；test: 測試用例新增、修改；build: 影響項目構建或依賴項修改；revert: 恢復上一次提交；ci: 持續集成相關文件修改；release: 發佈新版本；workflow: 工作流相關文件修改）

比如：refactor: 【utils】新增相對路徑轉換方法relativePath2FullPath