Git Worktree 與 Git Branch 開發的差異是什麼？在什麼情境適合使用 Git Worktree 開發？

開發新功能開發到一半，突然老闆跑來說有緊急 Bug 要修，你會怎麼辦？

大部分的人應該都是先 git stash 把剛寫一半的 code 塞進櫃子，然後切換分支去修 Bug。

但如果你改的東西涉及到大量的環境配置，或是切換分支後 node_modules 跟編譯後的檔案（Build Artifacts）會互相污染，那真的會讓人想摔鍵盤。

這時候，Git Worktree 就是你的救星了！

什麼是 Git Worktree？

你可以把 Git 的運作想像成「裝修房子」。

傳統的 git branch 當你切換分支時，房間裡的家具瞬間在你眼前消失，然後自動擺放成另一個任務的樣子。

雖然省空間，但缺點就是 「環境污染」。你得先把還沒洗的碗盤塞進櫃子，否則切不過去；而且切換後，空氣中可能還殘留著上一場工程的油煙味。

而 Git Worktree 則是直接在隔壁空地再蓋一間一模一樣的房子。

簡單來說，Git 底層的原理就是：

「一個靈魂（.git 資料庫），多個肉體（工作目錄）」。

你可以同時擁有「功能開發店」和「緊急維修店」兩個資料夾。左手在 A 視窗寫 AI 邏輯，右手在 B 視窗修 Bug，兩邊互不干擾，這才是真正的並行開發。

要在開發時保持心流，目錄結構跟環境配置是關鍵。

很多人第一次用 Worktree 會手殘把新目錄開在原本的專案資料夾內。千萬別這麼做！這會讓 Git 陷入無限遞迴的混亂。正確的 Git Worktree 蓋法是：

主基地（main）與任務分店（feature）平行放置。

# 在主基地執行建立 Worktree，但把 Worktree 目錄建立在原本專案外面的目錄
git worktree add ../my-app-feat-ai dev-branch

你的目錄結構看起來應該像這樣：

- my-project/       # 大型包裹
  - main-repo/      # 穩定的主基地
  - feat-ai-search/ # 正在施工的新分店

既然專案目錄分開了，你的 .env 設定檔也可以分開。

你可以在 feat-ai-search 連接測試用的資料庫，而在 main 維持原本的開發資料庫。這樣切換視窗時，連連線資訊都不用改。

進入 Worktree 目錄後，直接使用該 Worktree 目錄的環境變數進行開發，不用做任何的環境切換或重建整理，那種 「踩進去就開工」 的感覺真的非常爽。

在 Worktree 裡開發完後，流程跟傳統分支其實一模一樣，只是多了一個「拆遷」動作。

步驟流程	說明
1. 在分店提交（Commit & Push）	你必須親自走到分店現場才能簽字。
2. 總部驗收（Merge）	你可以回到 `main` 進行合併，或是直接發 Pull Request (PR)。
3. 優雅拆遷（Remove）	任務完成後，不要直接刪除資料夾，要用 Git 指令來拆遷：`git worktree remove ../feat-ai-search`

轟！ Worktree 臨時屋拆掉了，硬碟空間回來了，你的主基地依然乾乾淨淨。

Worktree 雖然好用，但還是有幾個坑要注意：

項目	說明
主基地不要亂搬家	因為 Worktree 紀錄的是絕對路徑。如果你改了主基地的資料夾名稱，Worktree 分店會因為找不到「靈魂」而暴斃。
分支不能雙開	同一個 Branch 不能同時在兩個 Worktree 被 Check Out。
掃地機器人 `prune`	如果你真的手殘直接用 `rm -rf` 刪了資料夾，記得執行 `git worktree prune` 把殘留在 `.git` 上的紀錄清乾淨。

不同的情境會使用不同的開發方式，沒有誰取代誰的問題，只有適不適合的問題。

情境	說明
日常小改動	繼續用 `branch`，輕便快速。
跨度大的任務	比如大規模重構、跨多個環境變數的調整、或是需要跟 AI 長時間協作的任務，開一個 Worktree 絕對是首選。

Git Worktree 不僅是一項指令，更是幫助我們維持開發心流的利器。下次遇到麻煩的跨度任務，不妨替自己開一間獨立的 「Git Worktree 分店」，感受那種從未有過的流暢開發體驗吧！