VSCode需直接打开工作树目录才能识别Git状态；该目录下应有指向主仓库.git/worktrees/的.git文件；确保Git版本≥2.25、插件启用多工作树支持，且工作树干净才可安全删除。
VSCode 打开工作树目录后不识别 Git 状态
VSCode 不是自动识别所有工作树，它只在你明确打开某个目录时才激活该工作树的 Git 集成。如果你执行了 git worktree add ../feature-x feature/x，但没用 VSCode 打开 ../feature-x 这个路径，编辑器根本不会加载它的分支、暂存区或文件状态。
常见错误现象包括：侧边栏源代码管理图标灰掉、git status 在集成终端里报错 “fatal: not a git repository”，或者状态栏显示 “No source control providers”。
- 确保用 VSCode 直接打开工作树目录（不是父目录，也不是主仓库目录）
- 检查该目录下是否存在
.git文件（不是文件夹）——它应该是一行内容，类似gitdir: /path/to/main-repo/.git/worktrees/feature-x - 如果用了 GitLens 或其他 Git 插件，确认它们未被禁用；部分插件需手动启用“多工作树支持”选项
- VSCode 的 Git 功能依赖系统级 Git 可执行文件，运行
git --version确保 ≥ 2.5，推荐 ≥ 2.25
创建工作树时加不加 -b 参数？
这个参数决定你是“检出已有分支”还是“新建并检出分支”。混淆会导致远程追踪关系缺失或本地分支未创建。
使用场景很明确：
- 想基于远程分支（如
origin/feature/login）拉取并创建本地同名分支 → 直接用git worktree add ../feature-login feature/login（不加-b） - 想新建一个本地分支（尚未存在），并立即在新工作树中检出 → 必须加
-b：git worktree add -b feature/new-ui ../feature-new-ui main - 想检出某个提交哈希（比如临时调试）→ 加
--detach：git worktree add --detach ../hotfix-test e7f3d2a
漏掉 -b 却以为创建了新分支，结果 git branch 里找不到，push 时还得手动 git push -u origin feature/new-ui 补上追踪关系。
多个 VSCode 窗口同时打开不同工作树，会冲突吗？
不会。每个工作树有独立的 index（暂存区）、HEAD 和工作目录，VSCode 启动时只读取当前打开路径下的 .git 引用，完全隔离。
但要注意几个实际影响点：
- 主仓库的
.git/config会被所有工作树共享 —— 比如你在一个工作树里执行git config user.name "Alice"，另一个工作树里也会看到这个设置 -
node_modules、venv、构建产物等完全独立，可放心npm install或make build，互不影响 - 如果两个工作树同时修改了同一文件（比如都改了
README.md），Git 不会自动合并 —— 因为它们属于不同分支，冲突只会在你后期git merge或git rebase时暴露 - VSCode 的全局搜索（
Ctrl+Shift+F）默认只搜当前打开的工作树，不是整个仓库
git worktree remove 删除失败怎么办？
最常见的原因是工作树目录里还有未提交更改，Git 默认拒绝删除以防丢数据。错误信息通常是：fatal: 'xxx' is not clean. Please commit or stash them.
处理方式取决于你是否还想保留这些改动：
- 想丢弃全部未提交内容 → 用
git worktree remove --force ../feature-x - 想保留但暂不提交 → 先进到该目录，执行
git stash push -m "wip-before-remove"，再删 - 误删了工作树目录但没运行
git worktree remove→ 剩余元数据会卡在.git/worktrees/下，后续git worktree list仍显示，但路径失效；此时应运行git worktree prune清理残留条目
别跳过 git worktree list 核对这一步。有些团队习惯把工作树建在 /tmp 或桌面，重启后路径消失，但 Git 还记着，不 prune 就一直报错。
