一个分支跑检查、另一个分支改 bug 时，可以给它们各放一个工作目录：
git worktree add ../repo-fix fix/cache
git -C ../repo-fix status
# 做完后回到主仓库清理
git worktree remove ../repo-fix
fix/cache 已经存在时可以直接这样用；想顺手新建分支则改成 git worktree add -b fix/cache ../repo-fix main。同一个分支不能同时被两个 worktree checkout，删目录前也最好先确认没有未提交改动。环境：Git 2.5+。
这个场景确实比 stash 来回切舒服。再补一个容易漏掉的点：手动删掉 worktree 目录后，Git 里可能还留着登记信息，可以跑 git worktree prune 清理失效记录。要是脚本频繁创建临时 worktree，也建议用独立临时目录，避免路径复用导致误操作。
FinleyLv1#1 这个场景确实比 stash 来回切舒服。再补一个容易漏掉的点：手动删掉 worktree 目录后，Git 里可能还留着登记信息，可以跑
git worktree prune清理失效记录。要是脚本频繁创建临时 worktree，也建议用独立临时目录，避免路径复用导致误操作。
还可以用 detached worktree 做一次性验收，不占用现有分支：
git worktree add --detach ../repo-check HEAD
# 检查完
git worktree remove ../repo-check
适合跑构建或复现某个提交；HEAD 也可以换成具体 commit。要保留改动的话，还是创建分支更稳。
隔壁空白Lv1#2 还可以用 detached worktree 做一次性验收，不占用现有分支：
git worktree add --detach ../repo-check HEAD # 检查完 git worktree remove ../repo-check适合跑构建或复现某个提交；
HEAD也可以换成具体 commit。要保留改动的话，还是创建分支更稳。
如果临时目录在可移动盘上，或者中途会被清理，git worktree lock ../repo-check --reason "验收中" 也挺有用，能避免 Git 把它当成失效 worktree。用完先 git worktree unlock ../repo-check，再正常 remove。
问问Lv1#3 如果临时目录在可移动盘上，或者中途会被清理，
git worktree lock ../repo-check --reason "验收中"也挺有用，能避免 Git 把它当成失效 worktree。用完先git worktree unlock ../repo-check，再正常 remove。
这个锁定点很实用。清理前可以先跑 git worktree list --porcelain 看实际路径和分支，确认目标没指错；remove --force 只在确认不要未提交改动时用，别拿它代替正常清理。这样和 prune、lock 配起来，临时 worktree 的生命周期就比较清楚了。
Nathan03Lv1#4 这个锁定点很实用。清理前可以先跑
git worktree list --porcelain看实际路径和分支，确认目标没指错；remove --force只在确认不要未提交改动时用，别拿它代替正常清理。这样和prune、lock配起来，临时 worktree 的生命周期就比较清楚了。
还有个搬目录时容易踩的坑：如果直接把 worktree 从一个路径挪到另一个路径，Git 里的登记路径可能没同步。确认新路径没问题后可以跑 git worktree repair /new/path 修复关联；正常用 git worktree move 会省掉这一步。修复前先 git worktree list --porcelain 看一下记录，避免改错目标。