AI 可以在短時間改很多檔案，Git 因此更重要。沒有乾淨起點、清楚 diff 和可回復的 commit，速度只會讓錯誤更快擴散。今天要把 Day 16 的重構放進一條可審查的 Git 流程。

從乾淨的起點開始

動手前先確認目前 branch、工作目錄狀態和基準 commit。若已有未提交修改，要先辨識來源，不讓 Codex 把別人的變更混進任務。新 branch 使用能表達目的的名稱，例如 refactor/task-title-validation；名稱本身不重要，重要的是能對應 Issue 和修改範圍。

每次完成一個可驗證的小步驟就查看 diff。先確認檔案清單，再讀實際內容；生成檔、格式化噪音或鎖檔大幅變動，都需要查明原因。不要等數十個檔案改完才第一次 Review，因為那時很難分辨哪一步引入問題。

怎樣切 Commit

Commit 應描述一個完整理由。例如先補保護現有行為的測試，再集中標題驗證，可切成兩個可獨立理解的 commit；若測試只為同一個小修改服務，也可保持一個 commit。不能只為追求數量拆出無法通過測試的中間狀態。

Commit 訊息寫結果和原因，例如「refactor: share task title validation」並在內容說明避免新增與編輯規則分歧。不要用「update files」或「AI changes」取代技術意圖。作者仍要看過內容，不能因為訊息是 AI 產生就直接接受。

交給 Codex 的 Git 任務

「先讀 git status 與 diff，確認任務開始前的狀態。只處理本次重構的檔案；每完成一個可驗證步驟就回報 diff 摘要和測試。提出 commit 切分與訊息，但在提交前先讓我確認內容。不得覆蓋或捨棄原有未提交修改。」

最後驗收包括 branch 只含預期 commit、每個 commit 可讀、測試結果能對應修改、沒有敏感資料或大型非必要檔案。需要撤回時，應能針對本次 commit 處理，而不是重設整個工作目錄。

今天的結果與限制

本文完成的是 Git 操作規則與 commit 驗收，尚未建立實際 branch 或 commit。實作時會記錄 Codex 是否碰到範圍外修改、我如何處理，以及最終 commit 是否能單獨 Review。

今天學到什麼？

Git 不只是備份工具，而是把 AI 的高速修改切成可理解、可驗證和可撤回的單位。下一篇會把這些 commit 整理成一份 Reviewer 看得懂的 Pull Request。