Featured image of post Vibe Coding 時代的 Git Worktree 實戰指南
AI

Vibe Coding 時代的 Git Worktree 實戰指南

探索 AI 驅動開發時代 Git Worktree 的實戰應用。本文帶你理解 Worktree 的運作機制，找出傳統 Git 工作流在 Vibe Coding 情境下的痛點，並提供多 AI 並行開發、實驗隔離等情境的完整解法。

一、AI 時代的開發模式轉變

「Vibe Coding」不是什麼新的程式語言或框架，而是一種全新的開發模式——AI 驅動的互動式開發。在這個模式底下，程式碼不再只是開發者一個人對著鍵盤敲出來的產物，而是人跟 AI 持續對話、一起摸索碰撞出來的結果。這代表軟體開發方式發生了一次根本性的轉變。

但這種轉變也讓傳統 Git 工作流的瓶頸浮出檯面。

1. 單一工作目錄的限制

傳統 Git 預設一個 repo 只对应一個工作目錄。但在 AI 輔助開發的情境裡，我們經常需要同時嘗試多種做法、走不同的實現路線，只有一個工作目錄根本不够用。

2. 切換分支的代價

切換分支這件事，實際上會在多個層面造成影響：

  • stash 的麻煩：切換前得先把改動 stash 起來，但 AI 並不知道這些檔案被收走了
  • commit 的壓力：頻繁建臨時 commit 會弄髒歷史，不敢 commit 又會失去回溯能力
  • context 斷掉：一切換，AI session 之前累積的上下文（對話紀錄、對專案的理解）瞬間歸零

3. AI session 是有連貫性的

Session A → Session B → Session C 不是單純的命令執行，而是有前後邏輯關聯的。AI 在這個過程中承載了：

  • 對話紀錄：理解使用者意圖的完整脈絡
  • 檔案狀態認知：AI「知道」目前檔案的結構和依賴關係
  • 思考脈絡：多次迭代累積下來的推理過程。AI 還會去讀 git commit 的歷史，理解程式碼是怎麼一步步演化成現在這樣的

切換分支會把這一切打斷，等於讓 AI「換一個腦袋」。最要命的是：沒辦法同時嘗試多種方案。傳統做法下，想試三種架構只能一個一個來：試方案 A → reset → 試方案 B → reset → 試方案 C。這種低效的迭代方式，跟 AI 能快速嘗試的特性直接矛盾。

二、Git Worktree 機制解析

1. 什麼是 Worktree

簡單講，Git Worktree 就是從同一個 .git repo 長出多個工作目錄的機制。這些目錄各自獨立，但又透過 branch 共享同一份歷史。

  • repo 共享：所有 worktree 共用同一個 .git 目錄，共享完整的 commit history、refs、objects
  • 獨立工作目錄：每個 worktree 有自己的目錄路徑，可以各自 checkout 不同的 branch。比如從 /path/to/ProjectA 派生出 /path/to/ProjectA-fix-bug 和 /path/to/ProjectA-new-feature
  • 分支獨占：同一個 branch 同一時間只能在一個 worktree 裡被 checkout

跟 clone 的差別：

1
2
3
4
5
6
7

# clone：建立一個完全獨立的 repo
git clone https://repo.url my-repo
# 結果：獨立的 .git、完整的 repo 副本、歷史各自管理

# worktree：共享同一個 repo
git worktree add -b feature-a ../feature-a
# 結果：共用 .git、共用歷史，只是多一個工作目錄

2. Worktree 的生命週期

生命週期

3. 基本指令 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 新建 worktree（同時建立新 branch）
git worktree add -b new-feature ../path/to/new-feature

# 新建 worktree（checkout 既有 branch）
git worktree add ../path/to/worktree existing-branch

# 列出所有 worktree
git worktree list

# 刪除 worktree
git worktree remove ../path/to/worktree

# 清理已刪除 worktree 留下的殘留資訊
git worktree prune

常用的參數：

  • -b <branch>：建 worktree 的同時建立新 branch
  • --detach：建 detached HEAD 狀態的 worktree（適合用來做一次性實驗）
  • --lock：鎖定 worktree，避免被 prune 誤刪

建議 worktree 的目錄名跟 branch 名保持一致：

1

git worktree add -b feature-auth ../project-feature-auth

三、為什麼 Vibe Coding 需要 Worktree

1. AI session 真正需要的東西

上下文的連貫性：AI session 不是執行完就結束的單次指令，而是一段持續進行的對話。

  1. 你：「幫我重構這個模組」
  2. AI：「我看了依賴關係，建議分三步處理……」
  3. 你：「第二步看起來有點問題」
  4. AI：「有道理，我重新調整一下……」

在這段對話中，AI 已經累積了：

  • 對專案結構的理解
  • 對你個人偏好的掌握
  • 之前嘗試過哪些做法的記憶

一切換分支，這條線就斷了。AI 得重新從零建立上下文。

工作環境的穩定性：AI 需要穩定的檔案狀態才能正常運作。檔案突然被 stash 或 reset，AI 的「認知地圖」就失效了：

  • 「我記得 auth.ts 的 API 介面是……咦，檔案怎麼不見了？」→ 被 stash 收走了
  • 「奇怪，我們剛才不是改過……」→ 被 reset 還原了，AI 的「記憶」跟現實對不上

實驗的自由度：AI 輔助開發最大的優勢就是可以快速反覆嘗試。但要真正發揮這個優勢，需要：

  • 實驗用的改動不會影響到主線
  • 多種做法可以同時並行存在
  • 行不通的嘗試可以隨時丟掉，沒有負擔

單一工作目錄做不到這些事。光是在分支之間來回切換，就足以讓狀況變得混亂。

2. 傳統做法的痛點

🔴 痛點 1：切分支 ＝ AI 上下文整個斷掉

情境：你在 develop 分支用 AI 開發 feature-A，突然收到緊急 bug 修復需求。

傳統做法：

  1. stash 目前的改動
  2. checkout 到 hotfix 分支
  3. 開新的 AI session 處理 bug
  4. 修完後 checkout 回 develop
  5. stash pop 還原改動 問題：原本的 AI session 已經斷掉，你得重新把 feature-A 的設計思路解釋一遍

🔴 痛點 2：AI 正在改檔案時 stash ＝ AI 找不到檔案

AI 正在編輯 config.ts，你突然需要切換分支。

你把改動 stash 起來、切換分支，但 AI 不知道檔案被收走了：

  • AI：「我繼續改 config.ts……」
  • 實際狀況：檔案已經被 stash，AI 改到舊版本去了

結果：stash pop 的時候直接產生衝突**

🔴 痛點 3：探索性的改動 ＝ 弄髒主線或反覆 reset

AI 嘗試三種架構：

  • 方案 A：改了 10 個檔案
  • 發現有問題，reset 回去
  • 方案 B：改了 8 個檔案
  • 還是有問題，再 reset
  • 方案 C：改了 12 個檔案

結果：主線分支被反覆 reset，commit 歷史整個亂掉；或者因為不敢 commit 而無法回溯之前的狀態

🔴 痛點 4：無法並行 ＝ 只能一個一個試

你想要：

  • 讓 AI-1 跟 AI-2 各自開發前端方案 A 跟方案 B，最後二選一
  • 讓 AI-3 跟 AI-4 比較不同後端演算法的效能
  • 讓 AI-5 跟 AI-6 嘗試不同資料庫 schema，在查詢效率和儲存成本之間找最佳平衡

傳統做法：只能串行。AI-1 試 → reset → AI-2 試 → reset → AI-3 試 效率損失：本來可以三個 AI 同時跑，卻被迫排隊，完全浪費了 AI 快速迭代的能力

四、實戰做法

1. 情境說明

你需要同時開發三個獨立的功能：

  • Feature-A：使用者認證模組
  • Feature-B：效能優化
  • Fix-C：修復某個緊急 bug

傳統困境：只能一個一個做，做完一個才能開始下一個。

Worktree 解法：

1
2
3
4
5
6
7
8
9

# 從主 repo 建立三個 worktree
git worktree add -b feature-auth ../project-auth
git worktree add -b feature-performance ../project-performance
git worktree add -b hotfix-a ../project-hotfix-a

# 各別啟動三個獨立的 AI session
cd ../project-auth && opencode          # AI-1 專注認證模組
cd ../project-performance && opencode   # AI-2 專注效能優化
cd ../project-hotfix-a && opencode      # AI-3 專注修 bug

2. 命名規則與目錄管理

命名慣例：

  • 功能開發用：project-feat-{功能名稱}
  • 實驗探索用：project-exp-{做法名稱}
  • bug 修復用：project-fix-{issue 編號}

保持一致的命名方式，管理跟辨識都比較方便。

建議的目錄結構：

1
2
3
4
5
6

~/project/
├── project-main-repo/     # 主 repo（不直接改程式碼，只做 merge、push 等操作）
├── project-feat-a/        # Feature-A 的 worktree
├── project-feat-b/        # Feature-B 的 worktree
├── project-exp-approach-x/# 實驗用 worktree
└── project-fix-123/       # Hotfix worktree

3. 清理與維護

清理：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 查看所有 worktree 狀態
git worktree list

# 清理已刪除 worktree 留下的殘留資訊
git worktree prune

# 刪除已完成的 worktree
git worktree remove ../project-feature-a

# 或者手動刪目錄後再執行 prune
rm -rf ../project-feature-a
git worktree prune

刪 worktree 之前先確認：

  1. 對應的 branch 是否已經 merge 到 main
  2. 有沒有還沒 commit 的重要改動
  3. 有沒有正在使用這個 worktree 的行程（例如還在跑的 AI session）

五、結語

Git Worktree 不是一個小技巧，而是為了配合全新開發模式而需要的系統性解法。傳統 Git 工作流誕生在「一個人連續工作」的年代，而 Vibe Coding 是「多 AI 並行、快速嘗試、重視上下文」的新時代。Worktree 剛好補上了這中間的落差。

開始用 Worktree 之後，你會發現：

  • 並行探索變成常態：多個 AI 同時跑，效率直接翻倍
  • 實驗不會再弄髒主線：放心試、不行就丟，主 repo 隨時保持乾淨