在過去的幾天裡，我們完成了 API 規格制定、Mock Data 測試與前後端串接代碼的自動生成。然而，現代軟體開發從來不是一個人的單打獨鬥，團隊協作與版本控制（Git）是每位工程師每天必須面對的功課。

相信很多人都經歷過這種場景：

• 忙了一整天改了一堆代碼，下班前只在 Commit 訊息隨便打個 fix bug、update 或 temp save。
• 發 PR（Pull Request）時，描述框一片空白，讓 Reviewer 必須一行行讀 diff 猜測你的意圖，大大拖慢合併流程。
• 幾個月後系統出了問題，用 git log 或 git blame 翻查歷史紀錄時，完全看不懂當時為何要這樣改。

今天我們就來示範：如何讓 ChatGPT / GitHub Copilot 扮演「版本控制助手」，根據 git diff 自動產出符合業界規範的 Conventional Commits 與結構嚴謹的 PR 審查文件！

一、什麼是 Conventional Commits 規範？

業界最廣泛採用的 Conventional Commits 格式如下：
():

[optional body]

[optional footer(s)]

常見的 Type 標籤：

• feat: 新增功能（Feature）
• fix: 修復 Bug
• docs: 僅修改文檔/註解
• style: 不影響代碼邏輯的排版、分號修正
• refactor: 重構（既非修 Bug 也非加功能）
• perf: 效能優化（Performance）
• test: 新增或修改測試代碼
• chore: 建置流程、依賴庫或輔助工具變動

二、Git Commit 生成提示詞模板（Diff-to-Commit Prompting）

當你準備要提交變更時，只需在終端機輸入：
git diff --staged

將輸出的變更摘要貼給 AI，並套用以下模板：

【Commit 訊息生成提示詞範本】
請扮演資深 Git 流程管理工程師。以下是我剛才變更的 git diff 內容：

[貼上 git diff 輸出]

請依序產出：

1. 嚴格符合 Conventional Commits 規範的單行 Commit 訊息（包含適當的 type 與 scope）。
2. 可選的詳細描述（Body）：以條列式說明「改動原因」與「影響範圍」。
3. 英文版與繁體中文版各一份，方便配合團隊習慣選用。

三、實戰案例：電商商品模組改動

假設我們剛才修改了商品列表 API，修復了分頁頁碼小於 1 時拋出異常的問題，並增加了關鍵字搜尋：

[終端機 git diff 範例]
diff --git a/src/api/productApi.ts b/src/api/productApi.ts
--- a/src/api/productApi.ts
+++ b/src/api/productApi.ts
@@ -15,4 +15,6 @@ export async function getProductList(query?: GetProductsQuery) {
+  const page = Math.max(1, query?.page || 1);
+  const keyword = query?.keyword?.trim();
   const response = await apiClient.get('/api/v1/products', {
-    params: query,
+    params: { ...query, page, keyword },
   });

AI 產出的標準 Commit 訊息：

【英文版推薦】
fix(api): sanitize pagination and trim search keywords in product listing

• Ensure page index is at least 1 to prevent IndexOutOfBoundsException
• Trim whitespace from keyword search query

【繁體中文版推薦】
fix(api): 修正商品列表分頁防呆與關鍵字空白過濾

• 將分頁頁碼限制為至少為 1，防止後端索引越界例外
• 去除搜尋關鍵字首尾空白字元，提升查詢精確度

四、一鍵生成 Pull Request (PR) 審查文件

當一個功能分支（Feature Branch）開發完成準備發 PR 時，手寫變更摘要通常非常耗時。我們可以用以下模板讓 AI 自動總結：

【PR 描述生成提示詞範本】
請扮演專業開源專案維護者。請根據以下這組 Commit 歷史與核心改動：
[貼上分支上的 Commit 清單或核心改動說明]

產出標準的 GitHub PR 描述 Markdown 範本，包含：

1. Summary（變更摘要）
2. Key Changes（核心改動清單）
3. How to Test（測試與驗證步驟）
4. Checklist（自我檢查清單）

AI 生成的 PR 描述範本：

📌 Summary

本 PR 解決了商品列表 API 在異常分頁參數下的邊界防呆問題，並優化了關鍵字搜尋的前處理邏輯。

🛠 Key Changes

• 防呆分頁：限制 page >= 1，避免使用者傳入負數或 0 導致伺服器 500 報錯。
• 字串清理：搜尋參數 keyword 增加 .trim() 去除首尾空白。
• 介面更新：同步更新 GetProductsQuery 的型別定義。

🧪 How to Test

1. 進入商品列表頁面。
2. 嘗試在 URL 帶入 ?page=0 或 ?page=-5，確認頁面自動以第 1 頁正常呈現，無報錯。
3. 搜尋欄位輸入帶有空白字串（例如 " 辦公椅 "），確認能精準撈出目標商品。

✅ Checklist

• [x] 代碼已通過本地 Linter 與 TypeScript 型別檢查
• [x] 未引入多餘的 console.log 或臨時註解
• [x] 相關單元測試皆已順利通過

五、進階技巧：在 VS Code 中善用 Copilot 快捷生成

如果你使用的是 VS Code + GitHub Copilot 插件，其實連複製貼上都省了：

1. Source Control 面板一鍵生成 Commit：
   在 VS Code 左側「原始檔控制（Source Control）」面板中，點擊 Commit 輸入框右上角的「閃爍星號圖示（Generate Commit Message）」，Copilot 就會自動分析當前 Staged 的所有變更，幾秒內自動填入高水準的 Conventional Commit！
2. 終端機 Copilot CLI 輔助：
   利用 gh copilot suggest "git rebase master into my branch"，也能在忘記進階 Git 指令時快速得到安全建議。

今日小結與預告

今天我們掌握了利用 AI 輔助產生 Conventional Commits 與標準 PR 文件的技巧，不僅大幅節省了手寫文件與紀錄的時間，更能讓團隊的 Git 歷史維持清晰、專業與可追溯性。