《Git 起來!》倒數五天,讓我們小小休息一下!又到了相對輕鬆、好理解的話題時間~
在專案裡打 git commit -m "修 bug"
,看似沒問題,但過一陣子回頭看,你可能會問自己:「是哪個 bug?哪裡修了?為什麼修?」😵
這篇要帶你認識 進階的 commit message 規範,讓你的每一次 commit 都是「自動產生 changelog 的文件」,也能幫團隊建立一致、可維護的開發流程。
在個人開發時,commit 只是紀錄;
但在團隊或開源專案中,它更是:
規範化的 commit message,讓 Git 不只是版本控制工具,更是開發流程的一環。
目前業界最常見的規範是 Conventional Commits。
格式非常簡潔:
<type>(<scope>): <subject>
範例:
feat(auth): 新增第三方登入(Google)
fix(ui): 修正按鈕 hover 狀態
docs(readme): 更新安裝教學
類型 | 用途 | 範例 |
---|---|---|
feat |
新功能 | feat: 新增會員註冊功能 |
fix |
修 bug | fix: 修正登入 token 過期問題 |
docs |
文件變更(例如 README) | docs: 補上 API 說明 |
style |
格式調整(不影響邏輯) | style: 統一縮排與引號 |
refactor |
重構(非新功能、非修 bug) | refactor: 重構驗證流程 |
perf |
效能優化 | perf: 提升渲染效能 |
test |
測試新增或修改 | test: 增加登入測試案例 |
build |
打包或相依套件變更 | build: 升級 Vite 至 v5 |
ci |
CI/CD 流程變動 | ci: 調整 GitHub Actions 設定 |
chore |
雜項、不影響功能 | chore: 更新 ESLint 設定 |
revert |
回復先前 commit | revert: 回復 "feat: 新增登入功能" |
(scope)
可以標示出這次修改影響的模組或功能:
Scope(範圍) | 說明 |
---|---|
core |
影響核心邏輯 |
api |
影響 API 相關功能 |
ui |
影響前端 UI |
auth |
影響身份驗證(Login/Logout) |
database |
影響資料庫相關功能 |
math |
影響數學模組 |
config |
影響專案設定(如 ESLint、Webpack) |
deps |
影響相依套件(依賴) |
例如:
feat(api): 加入 /users POST endpoint
fix(auth): 修正登入錯誤處理
這樣一看就知道影響範圍,不用再翻程式碼。
撰寫時記得幾個重點:
✅ 推薦:
fix(api): 修正回傳錯誤訊息格式
❌ 不推薦:
fixed the API return message bug.
若修改較大,可以在下一行空白後補上重點說明:
feat(auth): 新增第三方登入支援(Google)
- 新增 Google OAuth2 流程
- 後端 API 新增 /auth/google/callback
- 前端登入按鈕新增 loading 狀態
若本次修改會破壞相容性(breaking change),要特別標註。
feat!: 重構 API 結構,移除舊版 endpoint
feat(api): 調整回傳格式
BREAKING CHANGE: 所有回傳資料改為包在 data 屬性中
feat(login): 新增 Google 第三方登入
fix(ui): 修正 modal 無法關閉問題
refactor(api): 重構 fetch wrapper
docs: 補上環境變數說明
test(auth): 增加 refreshToken 測試
chore: 更新 prettier 設定
update login
fix bug
test ok
change something
feat(auth): 新增第三方登入支援(Google)
- 新增 Google OAuth2 流程
- 後端 API 新增 `/auth/google/callback`
- 前端登入按鈕新增 loading 狀態
BREAKING CHANGE: 移除原有的 Facebook 登入支援
結合規範 commit,可自動決定:
feat
→ minor 版號 +1fix
→ patch 版號 +1BREAKING CHANGE
→ major 版號 +1再搭配 changelog 生成工具(如 standard-version
或 semantic-release
),可全自動化版本發布流程。
一個健康的開發流程可能長這樣:
feat: 新增購物車功能
↓
fix: 修正購物車數量更新錯誤
↓
refactor(cart): 重構購物車邏輯
↓
feat!: 重構整個 API 架構(BREAKING CHANGE)
好的 commit message,不只是「為了漂亮」或「團隊規定」,而是讓每一次修改都有被理解、被追蹤的價值。
當 commit 本身就能解釋「為什麼改這樣」,你就不再需要翻一堆 code 來還原歷史。
從今天開始,讓你的 commit「會說話」吧 !