Git 全景課 / 第四部分　應用 · M13

M13　AI 時代的 Git

AI agent 寫得快、不會累，也會照字面執行命令。當幾個 agent 和人同時修改同一個倉庫，前面學過的每一樣東西——worktree、分支、PR、保護規則、commit 說明——都從「好習慣」變成「必需品」。本單元把它們組合成一套讓人和 AI 並行工作、正本仍然受控的做法。
約 60 分鐘互動 ×3 · 小測 4 題先修：M8、M10、M11
學完本單元，你能夠：
  1. 為幾個並行的 agent 設計 worktree 和分支，避免互相覆蓋；
  2. 說明為甚麼 AI 的改動應經 PR 合併，以及怎樣按風險分級審查；
  3. 用 commit 說明和 trailer 追溯哪些改動出自 AI；
  4. 為一個人＋AI 的倉庫設定合適的規則。

1AI 帶來的新問題 What changes with AI agents

情況風險對應的工具
幾個 agent 同時工作在同一個資料夾互相蓋掉檔案一個 agent 一張書桌（worktree，M8）
agent 照字面執行「推上去」未經審查的改動直接進正本保護規則＋清空繞過名單（M11）
agent 產生大量改動人沒有時間逐行看小 PR、CI、按風險分級審查（M10、M11）
事後追查分不清哪些是人寫的、哪些是 AI 寫的commit 說明＋trailer、分開的身份（M2、本單元）
agent 修改了歷史amend、rebase、強制推送蓋掉別人的工作黃金規則＋禁止強制推送（M7、M11）

2一個 agent 一張書桌 One agent, one worktree

M8 的規則在這裏最實用：每個 agent 有自己的 worktree（資料夾）和自己的分支。它們共用同一份歷史，卻不會碰到彼此未提交的檔案；Git 的「一條分支只能在一張書桌」規則，也防止兩個 agent 同時寫同一條分支。完成後，各自開 PR，經審查合併回 main。

命令作用
git worktree add ../wt-1 -b feat-1為一個 agent 開書桌，同時建立它的分支 feat-1
git worktree list列出所有書桌和各自攤開的分支
git worktree remove ../wt-1任務完成後收拾書桌（有未提交修改時會拒絕，要加 --force）
git worktree prune清理資料夾已被直接刪掉的書桌留下的記錄
書桌是分開的，抽屜和書架是共用的 每個 worktree 有自己的 HEAD、暫存區和工作檔案；但物件庫、分支和其他 ref、stash、hooks、設定（config）都是所有書桌共用的。所以一個 agent 執行 git stash pop，可能取走另一個 agent 存進去的改動；在一張書桌 git branch -D，別的書桌也就沒有那條分支了。給 agent 的規則：不要用沒有標記的 stash（寧可先做一個臨時 commit），不要刪除不是自己建立的分支。

互動 1　三個 agent 的工作分配

三個 agent 要同時工作。為每一個選擇資料夾和分支，並看它們會改哪些檔案。下方即時評估這個安排會出甚麼問題。

    3AI 開 PR，按風險分級審查 AI-authored PRs and tiered review

    AI 的改動一律經 PR 進入 main，保護規則（清空繞過名單）讓這一點不靠自覺。但如果每個 PR 都要人逐行看，AI 帶來的效率就沒了。一個常見的做法是按風險分級：

    級別例子誰審查、誰合併
    一級：低風險筆記、文件、拼字另一個 AI 審查（審查者與作者不同、只有讀取權），通過後自動合併
    二級：中風險腳本、排程、部署設定AI 審查後合併，合併後通知人（例如每日摘要）
    三級：高風險規則檔本身、權限、密鑰、刪除檔案、審查設定一律由人親自審查和合併

    關鍵是分級由規則（例如按檔案路徑）決定，而不是由寫改動的 AI 自己決定，否則它可以把高風險的改動說成低風險。審查者也必須和作者不同，不能審自己的 PR。

    分級也要由伺服器上的設定機械地執行，而不是靠 AI 守約定：

    注意：GitHub 不允許 PR 的作者批准自己的 PR。如果 agent 用你的帳號開 PR，你就無法以審查者身份批准它；要讓「需要審查」這類規則運作，agent 需要自己的帳號。

    互動 2　這個 PR 屬於哪一級

    按上表為每個 PR 分級，再按「對答案」。

    4追溯：哪些改動出自 AI Tracing AI changes

    幾個月後要問「這段是誰改的、為甚麼」時，歷史就是唯一的證據。三個做法讓 AI 的改動可以追溯：

    互動 3　從歷史找出 AI 的改動

    按下面的命令，看看各自篩選出甚麼。

    
  
    

    



    5一個人＋AI 的倉庫，怎樣設定 A checklist
    

      
  
    1. main 受保護：必須經 PR、禁止強制推送和刪除、繞過名單清空（M11）。審查人數可以是 0，因為只有你一個人。
      2. 
  
    2. 每個任務一張書桌：agent 在自己的 worktree 和分支上工作（M8）；很多 AI 工具會自動這樣做。
      3. 
  
    3. 先開 issue 再動手：較大的任務先寫一張 issue 說明目標和完成標準，PR 連回那張 issue。
      4. 
  
    4. PR 要小：一個 PR 一件事（M10）；要求 AI 在說明裏寫「改了甚麼、為甚麼、怎樣驗證」。
      5. 
  
    5. 按風險分級：規則檔、權限、密鑰相關的改動，永遠由人合併。
      6. 
  
    6. 可追溯：trailer 或獨立的作者身份；保留 PR 記錄。
      7. 
  
    7. 收拾：合併後刪除分支和 worktree；刪除前比較內容，不要只信 commit（M7 squash 陷阱）。
      8. 

    



    6對照與誤解 Easily confused
    

    
  
    讓 AI 直接推 mainAI 經 PR 合併
    
  
    
    速度最快多一步，但可以自動化（分級合併）
    
    
    出錯時錯誤立即進入正本，別人可能已經 pull在 PR 階段被 CI 或審查攔下
    
    
    記錄只有 commitPR 說明、審查意見、CI 結果
    
    
    撤銷要 revert，可能已有人基於它工作不合併就是了
    
      

    

    
  常見誤解
  
      
    
    • 「在提示裏叫 AI 不要直推 main 就夠了。」提示是約定；只有伺服器上的規則（而且不在繞過名單上）才是保證。
      • 
    
    • 「AI 寫的程式通過了 CI，就不用人看。」CI 只檢查寫成規則的事；權限、密鑰、規則檔仍要人看。
      • 
    
    • 「幾個 agent 在同一個資料夾開不同分支就好。」一個資料夾一次只能展示一條分支；切換會互相干擾。要用 worktree。
      • 
  
    

    



    7小測 Quiz
    

    
  
    
    1. 兩個 agent 要同時修改同一個倉庫。最合適的安排是：
    
    
    
    
    
  
    
  
    
    2. 分級審查時，誰決定一個 PR 屬於哪一級？
    
    
    
    
    
  
    
  
    
    3. AI 用你的 git 身份（同一個 user.email）提交。要找出 AI 參與的 commit，最可靠的是：
    
    
    
    
    
  
    
  
    
    4. 一個 AI 開的 PR 修改了 .github/workflows/ 裏的 CI 設定。按本單元的分級，應該：
    
    
    
    
    
  
    
  
    

    



    本單元重點 Summary
    


    延伸閱讀