
jiantw83andClaude Opus 5
5b740c236b
feat(branch-prep): 一律在獨立的工作樹上開工,不在原地切換分支
同一份 clone 上同時持有多顆工作包時,原地切分支有三種損耗,一種比一種難查:
未提交的變更擋路、建置產物跨分支混淆,以及 agent 讀到不屬於它那顆工作包的
程式碼——agent 是非同步的,它可能在分支已經被切走之後才去讀檔,而且不會察覺,
產出看起來完全合理,只是接錯了上下文。前兩種人會當場發現,第三種不會,
所以工作樹一律建立,不是「有衝突才用」。
建不起來就中止,不退回原地切分支:靜默降級會讓使用者以為自己在隔離環境裡,
其實在原地改。
分支與工作樹合併為一個原子動作(fetch 後一次 worktree add),並補上回滾——
git 在 worktree add 失敗時仍會把分支留下來,那是最難查的半成品:下一次重跑
會走到「目標分支已存在」那條路,起點從此不再是遠端的來源分支。
起點一律取自 origin/{來源分支},遠端沒有就中止,不退回本機同名分支;
本機分支可能落後好幾天,而這件事從輸出上完全看不出來。原「來源分支在遠端
已存在時 pull 而非重建」那條,用更強的方式達成同一個目的:根本不碰本機分支,
就沒有覆蓋他人進度的可能。
不設 upstream:此刻遠端還沒有這個新分支,--track 會把 upstream 指到來源分支,
之後 git pull 會把來源分支的提交拉進來。留給第一次 push -u 自然建立。
路徑由 owner/repo/分支名 正規化後取雜湊推導(lib 的 worktreePath),不查表、
不寫狀態檔,換機器算出來一樣。取雜湊而不是把斜線攤平成 -,是因為攤平會讓
feat/a-b/main 與 feat/a/b/main 撞成同一個目錄,而現行的分支命名規則恰好讓
這種形狀有機會出現。
議題 #40
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 16:27:43 +08:00
..
2026-09-17 16:27:43 +08:00
2026-09-17 07:07:00 +00:00
2026-09-17 08:23:23 +00:00
2026-09-17 06:59:37 +00:00
2026-09-17 07:39:43 +00:00
2026-09-17 04:44:46 +00:00
2026-09-17 06:30:22 +00:00
2026-09-17 06:06:10 +00:00
2026-09-17 07:39:44 +00:00
2026-09-17 04:44:45 +00:00
2026-09-17 16:27:43 +08:00
2026-09-17 08:23:25 +00:00
2026-09-17 06:06:10 +00:00
2026-09-17 06:59:37 +00:00
2026-09-17 06:50:34 +00:00
2026-09-17 06:06:09 +00:00
2026-09-17 06:59:37 +00:00
2026-09-17 06:30:23 +00:00