# 為什麼要使用 Conventional Commits?
方便追蹤修改原因：當需要找回過去改動的原因時，比起隨意的 commit message 更容易查找。
快速理解 log：只要看 log 就能知道這次改了什麼，不用再打開整個程式碼去猜。
提升維護效率：讓團隊合作或自己後續維護專案時更清楚、有效率。
# Commit Message 範例
# 格式
Markdown
<type>(<scope>): <description>
<body>
issue: #<issue number>
# 常用的 type 說明與範例
# feat
新功能、新介面、新流程
Markdown
feat(auth): 新增使用者登入功能
新增使用者登入 API，支援 email 與密碼驗證。
登入成功後會回傳 JWT Token，供後續 API 認證使用。
# fix
修 bug、邏輯錯誤、漏寫條件
Markdown
fix(post): 修正貼文新增功能時，未正確帶入使用者 ID
修正資料庫插入時，因變數命名錯誤導致 user_id 為空值的問題。
已新增對 user_id 的驗證，避免類似錯誤。
# refactor
改寫程式、但功能不變
Markdown
refactor(order): 重構訂單計算邏輯
將訂單價格計算邏輯拆成獨立模組，提升可維護性。
修正部分邏輯錯誤，優化程式可讀性。
# style
空格、命名、排版
Markdown
style(ui): 調整按鈕樣式排版
# docs
README、註解、說明文件
Markdown
docs(readme): 更新專案設定文件
新增 API 使用範例，補充專案啟動步驟與環境變數設定。
# chore
升版本、搬套件、加工具
Markdown
chore(build): 更新依賴套件版本
升級 Node.js 至 v20，更新主要依賴套件版本。
修正部分相容性問題。
# perf
效能提升、跑更快
Markdown
perf(order): 優化訂單查詢速度
改用索引優化資料庫查詢，降低查詢時間。
提升 API 回應效率。
issue: #55
另外還有 ci、build、test 等 type，適合有 CI/CD 或測試流程的專案使用。
📌 小提醒：
用 Conventional Commits 寫 message，最好保持一致，這樣回頭看 log 或生成 changelog 會更有效率。
# 最後的想法
初次進入職場的時候，我常看到舊專案的程式碼裡有很多註解，但問題是註解很少隨著程式碼更新。 結果就是，註解和實際的程式碼常常對不起來，反而會造成更多誤解。
這讓我開始思考：「如果註解不可靠，那我要怎麼更清楚記錄程式的變化呢？」 後來接觸到 Conventional Commits，才發現原來 commit message 也可以成為專案的紀錄方式。
對我來說，這是一個新的習慣：
註解不再是唯一的說明來源
commit message 本身就能幫助追蹤歷史、理解修改原因
雖然我還在練習怎麼把 message 寫得更精準，但已經開始感受到它對維護專案的幫助。