3-5 透過 Cursor 協助生成 Commit 訊息
2025年4月19日
在現代軟體開發中，版本控制是一個重要的環節。當完成一段程式碼或測試後，需要將其 commit 並提交 pull request (PR)，接著由其他團隊成員進行 code review。
這樣的流程帶來幾個好處：首先，若某段程式碼在上線前測試時出現問題，我們可以透過回滾 (rollback) 來避免有問題的程式碼持續存在於程式碼庫中；此外，提交 PR 並經過 code review，能確保程式碼的整體品質更易於維護。
在這整個過程中，寫好 commit 訊息會很重要。
在介紹如何使用 Cursor 生成 commit 訊息之前，想先談一個重要的概念 — Conventional Commits。這並非某個強制規範，而是業界逐漸發展出的一種寫 commit 訊息的方式。它的優點在於，當未來維護者需要回溯程式碼歷史時，能更容易找到特定的 commit。
許多人在撰寫 commit 訊息時，常常會用模糊的描述，例如「add a new feature」(新增功能) 或「update a feature」(更新功能)。這樣的訊息對於未來的維護者來說，往往難以理解具體內容。當需要快速定位某個有問題的 commit 時，如果訊息全是「新增功能」「更新功能」，在茫茫 commit 紀錄中幾乎無從下手。因此， Conventional Commits 應運而生。
Conventional Commits 的具體做法
Conventional Commits 的方式是在 commit 訊息前加上一個 prefix (前綴)，用以分類 commit 的類型。
舉例來說：
- fix：修復某個 bug。
- feat：實現某個新功能 (feature 的縮寫)。
- 其他常見前綴：如 **docs (**新增文件)、refactor (重構程式碼)、test (撰寫測試) 等。
有了這些前綴，其他維護者在查找特定 commit 時，就能快速根據類型篩選，過濾掉不相關的紀錄。例如，想找修復 bug 的 commit，直接搜尋以「fix」開頭的訊息即可。除了前綴外，commit 訊息的內容也需明確具體，避免過於籠統。例如，不要只寫「修了個 bug」，而應寫「fix: 修復登入頁面按鈕無反應的問題」，這樣未來查看時會更一目了然。
在 Cursor 中生成 Commit 訊息
了解 Conventional Commits 後，我們接著來看如何在 Cursor 中快速生成符合規範的 commit 訊息。以一個實際情境為例，假設我在 Git 側邊欄中看到兩個改動，一個是修改文件，另一個是新增測試。我會先將改動 stage (暫存) 起來，接著在 commit 欄位中點擊「Generate Commit Message」按鈕。
Cursor 會自動生成一條訊息，例如「test: 新增 memorize 函數的單元測試」。如果訊息沒問題，直接點擊 commit 即可完成。
為了讓生成的訊息更易讀、未來方便找，推薦每次 commit 的範圍盡量小，避免在單個 commit 中混雜多種類型的改動。例如，修改文件和新增測試應分開 commit，而不是一次提交。將同一類型的改動 stage 在一起，再生成訊息，這樣 prefix (前綴) 會更一致，內容也更聚焦。
確保 Cursor 遵循規範
若發現 Cursor 生成的訊息未遵循 Conventional Commits，可以透過設定 Cursor Rules 來修正。在設定頁面的「Rules」選項中，編輯 user rules，加入提示詞，例如：「生成 commit 訊息時，需遵循 Conventional Commits 規範，使用適當的 prefix（如 feat、fix、test 等）並提供明確具體的描述。」這樣能確保 Cursor 會按照規範生成訊息，既符合規範又清晰易懂。
此系列文章為 《給工程師的 Cursor 工作流 — 透過 AI 代理全方位提升開發生產力》 搭配的教材。希望透過這系列文章，將過去協助導入 AI 工具及使用 Cursor 的經驗擴展並分享給想提升生產力的讀者。如果對課程感興趣的讀者，可以加入 E+ 成長計畫，觀看影片學習。