iT邦幫忙

2025 iThome 鐵人賽

DAY 26
0
Modern Web

Git 起來!每日一招學起來系列 第 26

Day 26:Commit message 規範 —— 寫出能說話的 Git 訊息

  • 分享至 

  • xImage
  •  

《Git 起來!》倒數五天,讓我們小小休息一下!又到了相對輕鬆、好理解的話題時間~

在專案裡打 git commit -m "修 bug",看似沒問題,但過一陣子回頭看,你可能會問自己:「是哪個 bug?哪裡修了?為什麼修?」😵‍

這篇要帶你認識 進階的 commit message 規範,讓你的每一次 commit 都是「自動產生 changelog 的文件」,也能幫團隊建立一致、可維護的開發流程。


為什麼需要 commit message 規範?

在個人開發時,commit 只是紀錄;

但在團隊或開源專案中,它更是:

  • 追蹤歷史:快速知道哪次改了什麼
  • 自動化工具的依據:例如 changelog、semantic-release
  • 溝通文件:Reviewer 一看訊息就懂你的意圖

規範化的 commit message,讓 Git 不只是版本控制工具,更是開發流程的一環。


Conventional Commits 基本格式

目前業界最常見的規範是 Conventional Commits。

格式非常簡潔:

<type>(<scope>): <subject>

範例:

feat(auth): 新增第三方登入(Google)
fix(ui): 修正按鈕 hover 狀態
docs(readme): 更新安裝教學

Type 類型對照表

類型 用途 範例
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) 可以標示出這次修改影響的模組或功能:

Scope(範圍) 說明
core 影響核心邏輯
api 影響 API 相關功能
ui 影響前端 UI
auth 影響身份驗證(Login/Logout)
database 影響資料庫相關功能
math 影響數學模組
config 影響專案設定(如 ESLint、Webpack)
deps 影響相依套件(依賴)

例如:

feat(api): 加入 /users POST endpoint
fix(auth): 修正登入錯誤處理

這樣一看就知道影響範圍,不用再翻程式碼。


Subject 撰寫原則

撰寫時記得幾個重點:

  • 使用祈使語氣:「新增」「修正」而非「已新增」「已修正」
  • 不用句號結尾
  • 簡潔明確(50–72 字內)
  • 中文或英文皆可,但團隊需一致

✅ 推薦:

fix(api): 修正回傳錯誤訊息格式

❌ 不推薦:

fixed the API return message bug.

Body(可選,用來補充細節)

若修改較大,可以在下一行空白後補上重點說明:

feat(auth): 新增第三方登入支援(Google)

- 新增 Google OAuth2 流程
- 後端 API 新增 /auth/google/callback
- 前端登入按鈕新增 loading 狀態

BREAKING CHANGE(重大變更)

若本次修改會破壞相容性(breaking change),要特別標註。

寫法一(標題加驚嘆號)

feat!: 重構 API 結構,移除舊版 endpoint

寫法二(Body 補註說明)

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 登入支援

自動化版本管理(Semantic Release)

結合規範 commit,可自動決定:

  • feat → minor 版號 +1
  • fix → patch 版號 +1
  • BREAKING CHANGE → major 版號 +1

再搭配 changelog 生成工具(如 standard-versionsemantic-release),可全自動化版本發布流程。


整合 Git Flow 範例

一個健康的開發流程可能長這樣:

feat: 新增購物車功能
  ↓
fix: 修正購物車數量更新錯誤
  ↓
refactor(cart): 重構購物車邏輯
  ↓
feat!: 重構整個 API 架構(BREAKING CHANGE)

小結

好的 commit message,不只是「為了漂亮」或「團隊規定」,而是讓每一次修改都有被理解、被追蹤的價值。
當 commit 本身就能解釋「為什麼改這樣」,你就不再需要翻一堆 code 來還原歷史。
從今天開始,讓你的 commit「會說話」吧 !


上一篇
Day 25:git rebase -i —— 改寫歷史的時光編輯器
下一篇
Day 27:git reflog —— Git 黑盒子救回消失的紀錄
系列文
Git 起來!每日一招學起來30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言