Claude Code｜Git、差異審查與 PR

Claude Code 完成功能後，還需要檢查差異、整理提交並決定如何交給他人審查。本篇用待辦專案示範 Git 工作目錄、暫存區與提交的關係，最後準備一份 Pull Request 說明。你會知道測試通過、本機提交、遠端 PR、合併與部署是不同狀態。

請先完成Git 基礎，並準備一個你能管理的測試儲存庫。可以使用篩選功能或除錯成果。若這份資料夾尚未使用 Git，先在專用練習副本建立基準，再做一次小修改；不要拿不熟悉的工作目錄直接練習還原。

先查看目前差異

閱讀完整文字說明

Git、差異審查與 PR，以流程和文件圖形呈現教學重點。

在專案終端機查看分支、狀態與差異。git diff 看尚未暫存的變更，git diff --cached 看準備提交的內容。兩者可能同時存在，所以只看其中一份，不足以知道下一個提交到底包含什麼。

git branch --show-current
git status --short
git diff --stat
git diff
git diff --cached

檢查是否只有本次需求相關檔案。新增功能可能包含程式、測試與必要文件，但不應混入金鑰、測試輸出、另一個任務的草稿或整個下載 ZIP。若有不認識的修改，先查來源並保留，不要為了狀態乾淨而直接清除。

請 Claude 做有範圍的審查

請審查目前待辦篩選變更，先不修改。
重點是資料是否保留、勾選刪除是否依 id、測試是否涵蓋回歸。
列出具體問題、觸發方式與檔案位置；沒有證據的疑慮請標為待確認。
不要把一般風格偏好當成阻擋交付的錯誤。

審查回覆是另一份待核對的意見，不是正確性的最終保證。逐項看程式與測試，確認問題是否真的存在；若修正了審查發現，再執行受影響測試。沒有新改動或未解問題時，不需要無限重複審查同一份差異。

只暫存本次要交付的檔案

確定範圍後，使用明確檔名加入暫存區。下面是篩選功能的例子，請依實際檔名調整；如果測試檔不是 filter.test.mjs，不要照抄不存在的路徑。比起不看內容就 git add .，逐個確認更容易避免混入無關檔案。

git add -- model.js app.js index.html tests/filter.test.mjs
git diff --cached --stat
git diff --cached

暫存後若又修改檔案，新的部分不一定已在暫存區。提交前再看 git status，確認暫存差異與你剛測試的版本一致。不要把「這個檔案有加過」當成「目前所有內容都準備提交」。

建立能說明目的的提交

提交訊息描述最終行為，例如「加入待辦狀態篩選」，比「update」容易追查。你可以請 Claude 草擬訊息，但實際提交前仍要核對暫存內容。下面命令只建立本機版本，不會自動推到 GitHub。

git commit -m "Add todo status filters"
git status --short
git log -1 --oneline

如果提交失敗，閱讀 Git 的具體訊息。缺少使用者名稱與電子郵件時，先按自己的帳號與團隊習慣設定，不要直接使用教學中的假身分。若是檢查 Hook 失敗，先處理失敗原因，不要不看內容就略過所有檢查。

準備 Pull Request

如果你確定要分享測試儲存庫的分支，先核對遠端與分支名稱，再推送並在 GitHub 建立 PR。PR 的來源分支應是本次成果，目標分支應是團隊要接收變更的位置。不要只看 PR 標題正確，就忽略實際比較的兩個分支。

問題與結果：
待辦原本只能看全部，現在可切換全部、未完成與已完成。
篩選只影響顯示，勾選與刪除仍依 id 處理。

驗證：
- 實際執行的測試命令與結果。
- 瀏覽器操作的模式與資料保留檢查。
- 手機寬度檢查結果。

限制：
列出未驗證環境與本次仍保留的既有行為。

PR 說明應圍繞最終成果，不必重述所有聊天過程。若實作範圍後來改變，連標題與說明一起更新。審查者應能靠這段文字理解問題、改動與證據，而不需要回頭閱讀整段 Claude 對話。

PR 的審查者未必看過你與 Claude 的對話，因此描述要能獨立理解。開頭說明具體問題與修改後行為，再附相關驗證；例如原本切換第一個待辦會影響第二個，現在只更新指定識別碼，並增加不存在目標的回歸測試。

審查時同時看新增與刪除行，不只搜尋錯字。確認沒有誤刪測試、把錯誤吞掉或放寬輸入條件來換取通過。若更動產生的檔案與原始碼，應知道哪一份是來源、如何重新產生，避免只修改會被下一次建置覆蓋的結果。

推送後若遠端分支又有新提交，原本測試結果未必涵蓋目前版本。重新確認 PR 的來源分支、目標分支與提交識別碼，再決定需要重跑哪些檢查。合併完成也應到遠端核對實際結果，不能把本機 merge 命令成功當成遠端已合併。

交付筆記可以分成檔案修改、驗證、提交、PR、合併與部署六欄；沒有做的欄位直接標示未執行。這樣下一位接手者能從正確位置繼續，而不會重複已完成步驟或誤以為正式網站已更新。

CI、合併與後續交付

遠端 CI 可能使用不同作業系統與依賴版本，本機通過仍要查看 CI 結果。檢查完成後，確認審查意見與目標分支是否有新變更，再依團隊流程合併。不要把建立 PR 的成功訊息當成合併成功，也不要把合併當成部署已完成。

小練習是把一個篩選或除錯成果整理成單一清楚提交，寫出 PR 說明並逐項核對證據。若沒有遠端儲存庫，先保留本機提交與說明即可。完成判準是提交只含本次內容，描述能對上實際行為，而且你能說明成果目前停在哪一個交付狀態。

回 Claude Code 教學總目錄

• AI 工具
• 教學
• Claude Code