Git Commit Message 規範
Git
說實話，剛開始寫程式的時候，我的 commit 訊息都很隨便，什麼 "fix bug"、"update"、"test" 這種毫無意義的訊息滿天飛。
經過幾個月的實際使用，我整理了這套規範，現在團隊合作時大家都能清楚知道每次 commit 到底改了什麼。
基本格式
bash
<type>(<scope>): <subject>
<body>
<footer>為什麼要這樣寫？
讓人清楚得知道該次改動針對了什麼樣的特點做了變化，統一的格式也方便多人協作時閱讀。
Commit message 其實就三個部分：
- 標題（header） - 快速說明這次改了什麼
- 正文（body） - 詳細解釋為什麼要改
- 尾注（footer） - 關閉相關的 issue
標題怎麼寫
標題包含三個部分，其中前兩個最重要：
- 類型（type）- 必填，告訴別人這是什麼類型的修改
- 範圍（scope）- 可選，修改的範圍
- 主題（subject）- 必填，簡單說明做了什麼
Type 類型對照表
這個表格是我常用的分類，基本上涵蓋了日常開發的所有情況：
| 類型 | 說明 |
|---|---|
| feat | 新功能（這個最常用） |
| fix | 修復 bug |
| docs | 只改文件，沒動程式碼 |
| style | 改格式、縮排這些不影響功能的 |
| refactor | 重構代碼，沒加新功能也沒修 bug |
| test | 加測試或改測試 |
| chore | 改建構流程、更新套件這些雜事 |
| perf | 性能優化 |
| build | 改建構系統或外部依賴 |
| ci | 改 CI/CD 設定 |
| revert | 取消之前的 commit |
| merge | 合併分支 |
實際範例
bash
feat(search): add fuzzy search to the search bar
用戶反映搜尋功能不夠聰明，常常找不到想要的結果。
這次加入模糊搜尋，即使打錯字也能找到相關內容。
Closes #1234標題寫法
- type: 一定要準確，別偷懶都寫 feat
- scope: 不確定就不寫，總比寫錯好
- subject: 用動詞開頭，像是 "add"、"fix"、"update"，不要超過 50 個字
正文什麼時候寫
一開始我都不寫正文，但後來發現有些改動真的需要解釋。特別是那些「為什麼要這樣改」的原因，未來的自己會感謝現在多寫的這幾行字。
尾注的用途
主要是關聯 issue，像是 Closes #123 或 Fixes #456。這樣 GitHub 會自動關閉對應的 issue，很方便。