寫到前面
經常看到別人提交的代碼記錄裡面包含一些feat、fix、chore等等，而我在提交時也不會區分什麼，直接寫下提交信息，今天就來看一下怎麼個事，就拿 element-plus 舉例來看一下。
其實這麼寫是一種代碼提交規範，當然不是為了炫技，主要目的是為了提高提交記錄的可讀性和自動化處理能力。
當然如果團隊沒有要求，不這麼寫也可以。
git 提交規範
commit message = subject + ：+ 空格 + message 主體
例如： feat:：增加用戶註冊功能
常見的 subject 種類以及含義如下：
- feat: 新功能（feature）
用於提交新功能。
例如：feat: 增加用戶註冊功能
- fix: 修復 bug
用於提交 bug 修復。
例如：fix: 修復登錄頁面崩潰的問題
- docs: 文檔變更
用於提交僅文檔相關的修改。
例如：docs: 更新readme文件
- style: 代碼風格變動（不影響代碼邏輯）
用於提交僅格式化、標點符號、空白等不影響代碼運行的變更。
例如：style: 刪除多餘的空行
- refactor: 代碼重構（既不是新增功能也不是修復bug的代碼更改）
用於提交代碼重構。
例如：refactor: 重構用戶驗證邏輯
- perf: 性能優化
用於提交提升性能的代碼修改。
例如：perf: 優化圖片加載速度
- test: 添加或修改測試
用於提交測試相關的內容。
例如：test: 增加用戶模塊的單元測試
- chore: 雜項（構建過程或輔助工具的變動）
用於提交構建過程、輔助工具等相關的內容修改。
例如：chore: 更新依賴庫
- build: 構建系統或外部依賴項的變更
用於提交影響構建系統的更改。
例如：build: 升級webpack到版本5
- ci: 持續集成配置的變更
用於提交ci配置文件和腳本的修改。
例如：ci: 修改github actions配置文件
- revert: 回滾
用於提交回滾之前的提交。
例如：revert: 回滾feat: 增加用戶註冊功能
總結
使用規範的提交消息可以讓項目更加模塊化、易於維護和理解，同時也便於自動化工具（如發布工具或 changelog 生成器）解析和處理提交記錄。
通過編寫符合規範的提交消息，可以讓團隊和協作者更好地理解項目的變更歷史和版本控制，從而提高代碼維護效率和質量。