本文將介紹 Pull Request（PR）的用途，說明它如何協助討論變更，也會帶您學會直接在 IDE 中建立及檢視 PR。另外還會整理寫好 commit 的三項原則。這些基礎很重要：Claude Code 能替您準備及評論 pull request；了解 PR 是什麼、為什麼要用，才能明智地使用這些功能。
範例與介面截圖以 JetBrains IDE 為準；操作名稱和位置可能因版本而異。練習時請使用獨立的教學用 repository。在工作專案中，請遵循該專案的分支、commit 與推送規範。
為什麼需要 Pull Request
在團隊中，將變更納入共用分支之前，先討論一番很有幫助。Pull request 把提議的 diff、意見和檢查結果集中在同一處。個人專案也會使用 PR，讓您在合併前檢視自己的工作。
使用 PR 時，您會先提出合併提案。在 GitHub 上稱為 Pull Request，其他一些平台則稱為 Merge Request。實際流程由團隊決定。
Pull Request 就是一項正式請求："請從我的分支取回（pull）變更，並將它們合併（merge）到主要分支。"但 PR 不只是請求，也是討論、檢查和改善程式碼的平台，讓變更在進入 main 前能先經過把關。
Claude Code 可以透過 GitHub CLI 等工具準備 PR 標題、說明和分析。請先檢查草稿。建立 PR 或送出評論都會寫入 GitHub，因此只有在您要求時才會執行。
Pull Request 的標準工作流程
以下逐步說明新增功能時常見的流程。
建立分支前，請先檢查來源分支，以及它相對於 GitHub 上目標分支的 commit 清單。新的 PR 不該包含無關的本機 commit。別為了"同步"就直接推送它們；請選好工作的正確基底，並將先前的工作另外保留。
步驟 1. 為新工作建立分支。這裡的 PR 流程從獨立分支開始。假設我們要新增一份貢獻者指南，就建立 feature/add-contribution-guide 分支。
步驟 2. 修改內容並將分支推送到 GitHub。在新分支中建立 CONTRIBUTING.md 檔案（建立後按一下 Add），並寫下給其他開發者的說明。接著使用清楚的訊息執行 Commit and Push，例如 docs: Add contribution guide。
這是關鍵步驟。Pull Request 是以遠端伺服器上已存在的分支為基礎建立的。因此，建立 PR 前，務必先將新分支推送（push）到 GitHub。
在 IDE 中建立 Pull Request
請確認比較的兩個分支：base 是接收變更的分支，compare/head 則是包含您工作的分支。建立 PR 前，先檢視 commit 清單和 diff。
分支已經在 GitHub 上了，現在可以建立 Pull Request。
步驟 1. 開啟 Pull Requests 分頁。在 IDE 左側邊欄找到 Pull Requests 分頁。開啟後，按一下 + 圖示（或 Create Pull Request 按鈕）。
步驟 2. 填寫 PR 資訊。IDE 會開啟方便操作的介面。請仔細填寫主要欄位：
- 標題 - IDE 常會自動填入分支名稱或最近一次 commit 的訊息；請確認標題簡短清楚，能反映變更重點；
- 說明 - 詳細向同事說明您做了什麼，以及為什麼要做；
- 審查者（Reviewers） - 您邀請來檢查變更的人。是否必須取得核准，由 repository 規則決定；
- 負責人（Assignees） - 通常會指定自己，作為作者並負責處理審查後的修改。
按下 Create Pull Request 前，請再確認一次 base、head 和 diff。如果工作還沒準備好接受審查，而且平台支援此選項，您可以建立 Draft PR。無論是一般 PR 或 draft，能存取 repository 的人都看得到。
Code review：檢查與討論
PR 建立後，就進入最重要的階段：code review。同事可以開啟您的 PR，檢視所有變更並留下評論。
您可以直接在 IDE 的 Pull Requests 分頁查看所有討論。如果有人對某一行程式碼留言，您會收到通知，也能直接回覆，不必切換到瀏覽器。
如果有人要求修改，該怎麼辦？很簡單，不用另外建立 PR。請在這個 PR 原本的分支中修改程式碼、建立新的 commit 並推送。GitHub 上的 Pull Request 會自動更新，將新的 commit 加入原有討論。
Claude Code 也能參與 code review，檢視 PR 的變更並留下評論。把它當成多一雙眼睛很有幫助，但最終決定和程式碼責任仍由您和團隊承擔。
完成工作：合併並刪除分支
所有意見都處理完，而且團隊核准變更（您收到"核准"）後，就可以合併 Pull Request。通常由資深開發者執行；如果您在 repository 中有相應權限，也可以自行合併。
步驟 1. 合併。請檢查所有意見、必要的核准和檢查狀態。如果規則和權限允許合併，請依照專案規範選擇可用方式（merge、squash 或 rebase），再確認操作。變更會進入 PR 的目標分支，本例中是 main。
步驟 2. 刪除分支。合併後，feature 分支就不再需要，可以刪除，避免 repository 留下多餘分支。GitHub 會提供 Delete branch 按鈕。
合併後，請在本機切回 main、取得最新更新，並確認 PR 的結果已經包含在內。如果工作分支沒有留下需要保留的內容，也可以刪除本機分支。如果 IDE 無法用一般方式刪除，請先查明原因，尤其是以 squash 或 rebase 方式合併之後。
寫好 commit 的三項原則
好的 commit 不只訊息要清楚，納入的內容也要合適。遵循以下三項簡單原則，讓變更歷史保持清楚且實用。
原則 1：撰寫清楚的訊息
您的 commit 是留給團隊和未來自己的訊息。如果歷史裡全是"fix"或"update"，就派不上用場。常見格式之一是 Conventional Commits，它提供以下結構：
<類型>: <簡短說明>
類型是描述變更類別的簡短詞語：
feat- 新增功能；fix- 修正錯誤；docs- 修改文件；style- 調整格式，不影響邏輯；refactor- 修改程式碼，但不新增功能也不修正錯誤；test- 新增或修正測試；chore- 日常維護工作（更新相依套件、設定建置流程）。
範例：
- 不佳：
fixed bug - 良好：
fix: Correct user login validation - 不佳：
readme - 良好：
docs: Update installation instructions
請 Claude Code 遵循 repository 採用的訊息格式。如果團隊使用其他方式，Conventional Commits 並非必要。
原則 2：一個 commit 對應一項邏輯變更
別把 bug 修正、新功能和舊程式碼重構全塞進同一個 commit。這樣的 commit 很難審查，也幾乎不可能順利撤銷。每個 commit 都應該只處理一項明確工作。
- 不佳：一個 "Update user page" commit 同時新增頭像欄位、修正名稱驗證，還更改按鈕顏色；
- 良好：拆成三個 commit：
feat: Add avatar upload to user profilefix: Correct username validation logicfeat: Update button colors on user page
如果一時忙碌，在同一個檔案裡改了太多東西，IDE 也允許您不必 commit 整個檔案：在 Commit 視窗中展開檔案，只勾選與目前工作有關的片段（chunks）即可。
原則 3：檢查變更結果
合併前，請執行適合這次變更的檢查，並確認實際結果。修改文件和新增邏輯所需的檢查項目不會相同。
如果 repository 已設定自動檢查，PR 會顯示各項檢查的狀態。綠色標記只代表已執行的檢查通過，並不代表程式碼沒有任何錯誤。請確認執行了哪些檢查，以及還有哪些內容未驗證。自動化設定是另一個主題。
Claude Code 如何搭配使用
PR 正是 Claude Code 特別能派上用場的地方。請留意以下幾點：
- Claude 可以根據您的分支建立 pull request，並準備好標題和說明；您可以在 GitHub 建立 PR 前先檢查內容；
- 可以檢視 PR 的變更並留言，多一雙眼睛協助把關；
- 可以依照專案規範協助撰寫 commit 訊息；
- 可以協助解讀已設定的檢查結果，並指出尚未驗證的部分。
PR 的目的，是在程式碼進入 main 前先接受檢查。即使 PR 說明和部分 review 由 Claude Code 協助完成，最終核准和合併責任仍由人來承擔。按下 Merge 前，請先看清楚實際要合併哪些內容。
GO TO FULL VERSION