git worktree 可实现多分支并行开发：每个工作树为独立目录、共享同一 .git 数据库，避免 clone 和 stash/checkout；需确保主工作树干净、路径为空、分支存在，新目录中 .git 是指向主仓库的文件，.env 等忽略文件需手动或工具复制，git worktree list 为权威状态源，误操作后可用 prune 或 force remove 修复。
直接用 git worktree 就能开多个分支并行开发，不用 clone 多份仓库，也不用反复 git stash 和 git checkout。关键不是“能不能”，而是“怎么组织才不乱、不冲突、不丢配置”。
怎么用 git worktree add 创建隔离分支目录
核心是让每个分支拥有独立工作区，同时共享同一份 .git 数据库。操作前确保主工作树干净（无未提交修改），否则命令会拒绝执行。
- 指定路径必须是**不存在的空目录**，Git 不会自动创建父级路径，比如
git worktree add ../feature/login feature/login中，../feature目录得提前存在 - 分支名必须已存在（本地或远程），若想基于远程分支新建本地分支，先运行
git checkout -b hotfix/db --track origin/hotfix/db，再用worktree add -
.git在新目录里是个文件（不是目录），内容类似gitdir: /path/to/main/.git/worktrees/feature-login，别手动删它，否则工作树就“断连”了 - 创建后进新目录，
git status显示当前分支，git log --oneline看到的仍是完整历史，和主工作树完全一致
为什么 .env、.vscode 这类文件总在新 worktree 里丢失
因为 git worktree add 只检出 Git 跟踪的文件，而 .env、.vscode/settings.json 等通常被写在 .gitignore 里——它们不属于版本控制，但却是运行必需的。原生 Git 不管这个。
Git Worktree 多需求并行开发助手：在当前 worktree 目录独立开发、修改、提交代码，不跨目录。基于目录命名规范自动识别仓库归属（如 main-repo-feature‑a → main‑repo 仓库）。遵循最小改动原则，从需求分析到 commit 交付全流程负责。触发场景：用户在 ...
- 最简单做法：在主工作树里写个脚本，每次
worktree add后手动复制，比如cp .env ../feature/login/ && cp -r .vscode ../feature/login/ - 更可靠的方式是用工具封装，比如
branchlet或git-worktree-manager，它们支持配置post-add钩子，自动执行复制、npm install、甚至启动 dev server - 注意
.gitignore本身会被复制过去，但新 worktree 的忽略规则只对它自己生效，不影响其他工作树
git worktree list 显示路径错乱或状态异常怎么办
git worktree list 是唯一可信的“工作树注册表”，但它只读取 .git/worktrees/ 下的元数据。一旦你手动移动、重命名或删除了某个 worktree 目录，列表就会残留“幽灵条目”，甚至导致 git worktree prune 失败。
- 先确认是否真丢失：进对应目录，看
.git文件是否存在且内容可读；再运行git rev-parse --git-dir，输出应为/path/to/main/.git/worktrees/xxx - 如果目录已被删但列表还在，运行
git worktree prune清理（注意：它不会删磁盘文件，只清理元数据） - 如果
.git文件损坏或指向错误路径，别硬修，直接删掉该 worktree 目录，再用git worktree remove --force <path>从注册表里移除，然后重建 - 避免用 Finder / 文件管理器直接拖动 worktree 目录——这会破坏
.git文件的相对路径引用
多 worktree 场景下，git pull 和 git push 还安全吗
完全安全，但行为和单工作树一致：每个 worktree 的 pull/push 操作只影响它当前检出的分支，不会波及其他 worktree。真正容易出问题的是本地未提交改动 + 切换分支 + 忘记检查状态。
-
git pull在 A 分支 worktree 执行，只更新 A 分支的本地引用和对象数据库，B 分支 worktree 里的git status不会变，但下次git fetch后能看到新提交 - 所有 worktree 共享一个 reflog，所以
git reflog在任意目录下看到的都是全局操作记录，别靠它判断“我在哪个 worktree 提交过” - 最危险操作：在 A worktree 修改了未跟踪文件（如
.env），又在 B worktree 里运行git clean -fd——它会删掉 B 目录下的未跟踪文件，但 A 目录的同名文件不受影响，这点常被误判为“文件丢了” - CI/CD 脚本里慎用
git worktree，某些环境（如 Docker 容器）挂载路径不一致，.git/worktrees/可能无法正确映射
worktree 的本质不是“多开几个文件夹”，而是把 Git 的分支指针和工作区解耦。真正难的从来不是命令怎么敲，而是每个 worktree 的职责边界是否清晰——比如是否允许在 hotfix worktree 里改 feature 代码，或者要不要给每个 worktree 配独立的 package-lock.json。这些决策比工具本身更能决定你能否长期稳定地并行开发。
