Claude Code 配合 Git：整理差異、提交說明同 PR 草稿

先睇改咗乜，再寫說明

Claude 可以幫你整理提交訊息同 PR 草稿，但唔應只憑分支名猜改動理由。一份格式漂亮嘅說明，如果同實際差異唔符，反而會誤導之後查紀錄嘅人。

開始前先睇工作目錄：

git status --short
git diff --stat
git diff
git diff --cached

未暫存、已暫存同未追蹤檔案係三回事。發現其他人嘅改動，先釐清歸屬，唔好一併整理、暫存或者清除。

1. 寫低團隊實際規矩

喺 CLAUDE.md 放必要背景，唔好照抄別人用嘅分支策略：

## Git 工作規矩
- 先查看工作目錄狀態，唔好將其他人嘅改動一齊納入。
- 提交格式：type(scope): subject。
- type 按實際用途選 feat、fix、docs、test、refactor 或 chore。
- PR 說明先講問題同改後行為，再列驗證同限制。
- 工單 ID 只用已提供或已核對嘅資料，唔好自行編造。
- 未明確要求時，只整理差異同草稿，唔提交、推送或合併。

格式限制、分支名稱同測試要求按團隊調整。指示檔係協作約定，真正分支保護同必要檢查要喺 Git 平台設定。

2. 起草提交訊息

讀取今次指定檔案嘅完整差異，以及相關測試結果。

提出一個符合團隊格式嘅提交訊息，主旨講最主要改動，內文解釋已知原因。唔知道原因就列明要補資料，唔好從程式猜成事實。

如果包含幾件無關工作，建議點分開。只提供草稿同檔案清單，唔暫存、唔提交。

例如修正空清單顯示，說明應該指出觸發條件同改後結果，唔只寫「更新元件」。亦唔好將未跑測試寫成已通過。

3. PR 說明要覆蓋整條分支

先確認比較基準分支同完整提交範圍，再讀整體差異，唔好只睇最後一個 commit。

按專案 PR 範本起草：原本問題、改後行為、必要技術取捨、實際驗證同剩餘風險。測試結果附執行指令；未跑嘅項目標明原因。

唔建立或發佈 PR，保留草稿畀我核對。

如果後來改咗範圍，重寫說明去反映最後結果，唔需要將所有嘗試過但放棄嘅方案都塞入去。Monorepo 則要交代影響邊幾個套件、下游使用者同版本安排。

4. 衝突唔係揀左邊定右邊

處理 rebase 或 merge 衝突前，先確認目前操作、未完成步驟同兩邊提交意圖。Rebase 入面嘅 ours／theirs 容易令人誤會，唔好只靠名稱揀一邊。

目前 [merge／rebase] 出現衝突，檔案係 [路徑]。

讀共同基準、兩邊相關提交同呼叫端，解釋各自想改乜。提出保留必要行為嘅結果；如果兩個要求互相矛盾，清楚列出決策點。

唔好為咗消除標記而將兩段程式直接拼埋。提出修正後要跑嘅測試，暫時唔繼續 Git 操作或推送。

衝突標記消失只代表文字層面處理完，仍要驗證行為。重新整理共享歷史、強制推送、刪分支同回復工作目錄，都要有清楚範圍同復原安排。

檢查工具放喺啱嘅位置

Git commit-msg hook 可以檢查提交訊息；CI 同分支保護可以限制合併。Claude Code 嘅 PostToolUse 喺工具執行後先觸發，唔可能阻止已完成嘅 commit，亦唔會自動復原。

秘密資料掃描可以補一層檢查，但 .gitignore 唔會移除已追蹤檔案，格式檢查亦唔會驗證說明係咪真。最後仍要讀將會提交嘅差異同檔案清單。

Git 自動化有用嘅地方，係減少重複整理，唔係代你判斷共享歷史可以點改。