這個功能改變的,是 worktree 本身的行為,還是只有輸入的方式?
只有輸入的方式改變,worktree 建立出來之後的行為完全一樣。無論你是貼一個純數字加 #、一個 GitHub pull request 網址,還是一個 GitLab merge request 網址,Claude Code 最後都會解析出同一個核心資訊——這是第幾號的變更請求,然後照著同一套邏輯,從你 repository 的 origin remote 抓取對應的 head commit,建立在同一個命名規則的目錄底下(.claude/worktrees/pr-<number>)。
換句話說,這次更新解決的是「你要用什麼格式告訴 Claude Code 你想要哪個變更」這個輸入層面的問題,不是改變 worktree 建立、隔離、管理的核心邏輯——那一整套機制在這次更新前後是一致的。
為什麼這種「支援更多輸入格式」的小改動值得特別拿出來講?
單看這一個功能,確實只是省下一道手動轉換的步驟,影響範圍不大。但它反映的是一個更廣的模式:Claude Code 原本的很多功能,是先以 GitHub 為預設對象設計出來,GitLab 支援往往是後續才補上的——這種先後順序,經常會讓 GitLab 使用者在某些細節上,比 GitHub 使用者多繞一道路,即使功能本身兩邊都有。
--worktree 這次的更新,是把這個特定的落差補平——GitLab 使用者現在可以用跟 GitHub 使用者完全對等的方式(直接貼網址)使用這個功能,不需要自己在腦中做格式轉換。對於團隊裡同時有人用兩種平台的情境,這種「輸入方式對齊」比單一功能本身的價值更大一些,因為它降低的是團隊內部因為工具習慣不同而產生的溝通成本。
貼上網址之後,Claude Code 實際上是怎麼把對應的變更抓下來的?這個過程我需要做什麼設定嗎?
不需要額外設定,整個抓取過程是自動的。Claude Code 只會從網址裡讀取「編號」這一個數字,實際抓取變更內容時,一律透過你 repository 已經設定好的 origin remote 進行,不會另外去連線到網址裡寫的那個網域——這代表就算你複製貼上的網址跟你 repository 實際的 remote 設定不完全一致,只要編號是對的,抓取依然會成功,因為系統認的是 origin 的設定,不是網址本身的網域。
抓取路徑則依照 origin 指向的主機類型自動判斷:如果是 GitHub Enterprise、自架的 GitLab,或其他類型的主機,系統會先嘗試 pull/<number>/head 這個路徑,如果失敗,再退回去嘗試 merge-requests/<number>/head——這個「先試一種、失敗再試另一種」的機制,是這次更新才加上去的,在 2.1.233 之前,系統固定只嘗試 pull/<number>/head 這一種路徑。
如果我的團隊 GitHub、GitLab 都在用,實際上該怎麼利用這個更新調整團隊的工作習慣?
最直接的調整,是不需要再為兩種平台維護兩套不同的「怎麼跟 Claude Code 說要處理哪個變更」的操作說明——過去可能得跟 GitLab 使用者特別交代「先去 MR 頁面找編號,再用 # 加數字」這種額外步驟,現在可以統一成一句話:「把 MR 或 PR 的網址直接貼給 --worktree」,不用區分對方用的是哪個平台。
比較細節的地方是,如果團隊裡有自架的 GitLab 或 GitHub Enterprise,實際抓取時系統會先試 pull/<number>/head、失敗才退回 merge-requests/<number>/head——如果團隊自架的環境本身路徑命名邏輯比較特殊(例如經過反向代理或客製化過 API 路徑),遇到抓取失敗時,值得先確認是不是這兩個標準路徑都對不上你的環境,而不是直接假設是 --worktree 這個功能本身壞掉了。
Claude Code 2.1.233 版本(在 2026 年 8 月的更新序列裡)為 --worktree 加了一個小但實用的改動:現在可以直接把一個 GitLab merge request 的網址貼給它,不需要自己先去查出對應的編號、也不需要手動轉換格式。這篇整理這個功能實際怎麼用,以及它跟舊行為的差異在哪裡。
--worktree 讓你可以在不影響主要工作目錄的情況下,單獨為某個分支建立一個獨立的 checkout——常見情境是你正在處理一個功能分支,這時候臨時需要去看某個 PR 或 MR 的內容,不想因此打斷手上正在做的事,也不想 stash 目前未提交的變更。透過 worktree,你可以直接開一個獨立目錄,讓 Claude Code 在那個目錄裡處理另一件事,兩邊互不干擾。
在這次更新之前,--worktree 只接受兩種輸入:用 # 開頭加上數字(例如 #123),或是 GitHub 格式的 pull request 網址。如果你的專案是用 GitLab,想要透過 worktree 處理一個 merge request,你得先自己從 MR 頁面找到對應的編號,再手動組出 # 加數字的格式貼給 Claude Code——多一道轉換步驟,而且如果團隊裡同時有人用 GitHub 也有人用 GitLab,這種輸入格式的不對稱容易造成困惑。
現在你可以直接把類似 https://gitlab.com/group/repo/-/merge_requests/123 這樣的完整網址貼給 --worktree,Claude Code 會自己從網址裡解析出數字部分,不需要你事先轉換。實際抓取變更內容時,Claude Code 一律從你 repository 的 originremote 抓取該次變更的 head commit,並依照 origin 指向的主機類型決定抓取路徑——如果是 GitHub 或自架的 GitLab,系統會先嘗試 pull/<number>/head,失敗的話再退回嘗試 merge-requests/<number>/head。建立出來的 worktree 會固定存放在 .claude/worktrees/pr-<number> 這個路徑下,不管你貼的是 GitHub 網址、GitLab 網址還是單純數字,產生的目錄命名邏輯是一致的。
因為網址裡的 # 符號在多數 shell 環境下會被當成註解的開頭,如果你是直接用純數字加 # 的格式(例如 #123),記得要把整個參數用引號包起來,否則 shell 可能會把 # 之後的內容整段忽略掉。另外,因為 worktree 本質上是一個全新的 checkout,你主要工作目錄裡沒有被 git 追蹤的檔案(例如 .env、.env.local 這類本機設定檔)不會自動出現在新建立的 worktree 裡——如果你的任務需要用到這些檔案,得自己手動複製過去。