2 Commits

Include renames

Author	SHA1	Message	Date
jiantw83andClaude Opus 5	865561c63b	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 15:54:27 +08:00
jiantw83andClaude Opus 5	d153a49c47	feat(branch-prep): 依命名規則備妥開工的分支 ... 命名規則照議題 #1：從開發分支長出 {類型}/{需求描述}/main，從功能分支長出時前兩段沿用 來源，子分支才會留在同一棵樹下。需求描述由議題標題翻譯，那是 agent 的事，所以這裡只收 --slug 並驗格式：英文 kebab、≤40 字元，中文分支名會讓 CI 與 URL 出問題。 三處「不弄丟別人的東西」，而且全部在任何 git 寫入之前判斷完： - 工作區不乾淨就不動手。未提交的改動與未追蹤的檔案都會跟著 checkout 走到新分支上， 混進這顆工作包的 commit；目標分支已存在時，git 還會拖到 checkout 那一步才拒絕， 屆時 fetch 與 merge 都已經跑掉了。 - 來源分支在遠端已存在時 pull 而不是重建。 - 目標分支已存在時接上去而不是從來源蓋掉。 遠端分支的比對用全名 refs/heads/<ref>：ls-remote 的樣式比對吃的是 ref 尾段，而本 repo 的命名慣例讓每一支分支都以 /main 結尾——用短名比對，拿 main 當開發分支的專案會把 feat/x/main 誤認成 main，整個判成「遠端已經有這一支」。 算與做分成兩段，--dry-run 印出的就是真正將執行的那幾行 git，不另外維護一份描述。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 07:07:00 +00:00