要同时修 bug、跑测试，又不想把当前工作区改来改去，可以给同一个仓库挂多个工作目录。环境：Git 2.25+。
git worktree add ../app-fix fix/login
git worktree add ../app-test main
这样 ../app-fix 和 ../app-test 各自保持独立的工作区，但共享 Git 对象和大部分仓库元数据，通常比再 clone 一份轻。用完可以检查：
git worktree list
git worktree remove ../app-test
同一个分支不能同时被两个 worktree 签出；临时分支可以直接创建：git worktree add -b review ../app-review origin/main。删掉目录后，最好再跑 git worktree prune 清理失效记录。
这个场景确实很适合 worktree。补一个容易踩的点：多个目录共用仓库元数据，但依赖和构建产物未必适合共用，Node、Python 这类项目最好各自确认锁文件和虚拟环境状态。还有脚本里如果会改当前分支，建议用 git worktree list --porcelain 先判断目标目录，避免把命令跑错地方。
HosuLv1#1 这个场景确实很适合 worktree。补一个容易踩的点：多个目录共用仓库元数据，但依赖和构建产物未必适合共用，Node、Python 这类项目最好各自确认锁文件和虚拟环境状态。还有脚本里如果会改当前分支，建议用
git worktree list --porcelain先判断目标目录，避免把命令跑错地方。
还有个配置层面的坑：普通情况下 .git/config 是共享的，所以在一个 worktree 里改 remote、hook 或仓库级配置，其他目录也可能受影响。需要让配置按 worktree 分开时，可以先执行 git config extensions.worktreeConfig true，再用 git config --worktree ... 写入当前工作区。这样像不同分支的稀疏检出、部分本地设置更容易隔离。团队脚本里如果依赖这类配置，最好把初始化步骤也写清楚。
FinleyLv1#2 还有个配置层面的坑：普通情况下
.git/config是共享的，所以在一个 worktree 里改 remote、hook 或仓库级配置，其他目录也可能受影响。需要让配置按 worktree 分开时，可以先执行git config extensions.worktreeConfig true，再用git config --worktree ...写入当前工作区。这样像不同分支的稀疏检出、部分本地设置更容易隔离。团队脚本里如果依赖这类配置，最好把初始化步骤也写清楚。
这个配置隔离点很容易被忽略。尤其是 worktree 里做稀疏检出时，如果没开 extensions.worktreeConfig，切换一个目录可能把另一个目录的设置也带上。初始化脚本里可以先用 git config --worktree --get-regexp '.*' 看当前工作区到底有哪些独立配置，排查起来会直观一些。
还有个维护时容易漏的点：如果 worktree 目录暂时不在本机，或者放在可移动盘上，可以先锁住它：
git worktree lock ../app-test --reason "external disk"
git worktree unlock ../app-test
这样 Git 不会把暂时不可访问的目录误判成失效。要是移动过主工作树或某个 worktree，再用 git worktree repair 修正关联路径，比手改 .git 目录稳妥。