vs code 原生支持 git 工作树，需 git ≥2.5 且直接打开工作树目录（非主仓库根路径），通过读取 .git 文件内容识别；每个工作树须单独打开窗口，提交共享数据库但需手动 fetch 才可见新 commit；删除前必须关闭对应 vs code 窗口。
VS Code 对 Git 工作树（git worktree）的支持是原生的，不需要插件就能识别、切换和管理多个工作树目录——但前提是你的 Git 版本 ≥ 2.5，且 VS Code 打开的是工作树目录本身，不是主仓库根路径。
VS Code 怎么识别一个目录是 Git 工作树？
VS Code 不会主动扫描或“发现”工作树；它只在你**直接打开某个工作树目录**（比如 ~/myproject-hotfix）时，通过读取该目录下的 .git 文件内容来判断是否为工作树。这个文件不是文件夹，而是一个纯文本链接，内容类似：
gitdir: /Users/you/myproject/.git/worktrees/hotfix
一旦识别成功，VS Code 左侧“源代码管理”面板右上角会显示当前分支名，并自动加载该工作树独有的暂存区与未提交更改——和主工作目录完全隔离。
- 如果你误打开的是主仓库根目录（
~/myproject），VS Code 就只会显示主分支状态，其他工作树对它不可见 - 每个工作树目录必须单独用 VS Code 打开（新开窗口或新窗口 → 文件 → 打开文件夹），不能靠“添加文件夹”到已有工作区
- VS Code 不会自动刷新工作树列表；新增工作树后，需手动打开对应路径
创建工作树后 VS Code 不显示分支或 Git 面板空白？
常见原因是 Git 没有完成初始化或 VS Code 缓存了旧状态。先确认该目录确实是一个有效工作树：
git worktree list
如果输出中包含你的目标路径，再检查该目录下是否存在 .git 文件（不是文件夹）且内容指向 worktrees/xxx。若一切正常但 VS Code 仍无反应：
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 关闭该窗口，再重新用“文件 → 打开文件夹”打开该路径（不要用“添加文件夹”）
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），执行Developer: Reload Window - 检查 VS Code 底部状态栏左下角是否显示 Git 分支名；不显示说明 Git 扩展未激活该上下文
为什么在工作树里提交后，其他工作树看不到新 commit？
这是正常行为，也是工作树设计的核心：所有工作树共享同一份 Git 数据库（.git 目录），所以提交、推送、拉取都会实时同步。但「看到新 commit」的前提是——你在另一个工作树里执行了 git fetch 或 git pull，或者 VS Code 自动触发了 fetch（默认开启，但可能被禁用）。
- VS Code 的 Git 自动 fetch 默认每 5 分钟检查一次远程更新，但**不会自动 fetch 本地分支的新 commit**
- 想立刻看到其他工作树刚提交的内容，需在当前工作树终端手动运行
git fetch，然后刷新分支视图 - 注意：
git pull是fetch + merge，在工作树中慎用，尤其当你当前分支和其他工作树不一致时，可能意外合并
删除工作树前必须关掉 VS Code 窗口吗？
必须。VS Code 会在工作树目录中持有文件句柄（尤其是 .git/index 和构建产物），若强行用 git worktree remove 删除，Git 会报错：
fatal: 'xxx' is locked: already checked out at 'yyy'
这不是权限问题，而是 VS Code 进程正在使用该工作树的 Git 状态。安全操作顺序是：
- 关闭对应 VS Code 窗口（确保没有终端、调试会话、watch 进程残留）
- 确认无其他编辑器或命令行在该路径下活动（
lsof +D /path/to/worktree可查 macOS/Linux） - 再执行
git worktree remove /path/to/worktree - 最后手动删除空目录（
rm -rf），Git 不会帮你清空文件夹
最容易被忽略的一点：VS Code 的“设置同步”或扩展缓存有时会保留已删除工作树的 Git 配置痕迹，导致下次打开同名路径时异常；遇到这类情况，可临时关闭 Git 扩展再重试。
