git worktree 必须创建在仓库父目录下，如 ../myapp-test-branch，不可在仓库内；每个工作树需独立 npm install、.env 和 Docker 构建上下文，并安全清理以防丢失未提交更改。
git worktree 创建测试分支目录时，路径必须在仓库外
直接在当前仓库内创建工作树会失败，Git 明确禁止 git worktree add 在同一仓库根目录或子目录下操作。错误信息通常是：fatal: 'xxx' is not a valid path 或 working tree already exists。
正确做法是把新工作树放在仓库父目录下，比如你的项目在 /home/user/myapp，那就用：
git worktree add ../myapp-test-branch test/202607
这样既避免路径冲突，又方便后续用 VS Code 单独打开该目录作为独立窗口——每个窗口天然隔离，不会互相影响 node_modules、.env 或构建产物。
- 别用相对路径如
./test-branch，它会被 Git 拒绝 - 路径名建议带分支名或用途（如
../myapp-hotfix-urgent），避免后期混淆 - VS Code 打开该目录后，源代码管理视图自动识别为独立工作树，分支状态、暂存区完全分离
测试环境依赖隔离：npm install 和 .env 不能共用
多个工作树共享同一个 .git 目录，但文件系统是独立的——这意味着 node_modules、dist、.env 等必须各自安装和配置，否则会出现版本错乱或敏感信息泄露。
常见错误是：在一个工作树里 npm install 后，另一个工作树直接运行 npm run test，结果因 node_modules 缺失或版本不一致而报错 Cannot find module 'xxx'。
- 每个工作树首次使用前，必须单独执行
npm install（或yarn install） -
.env文件不要提交到 Git，且每个工作树应有自己独立的副本（例如.env.test、.env.staging） - 如果用 pnpm，注意
pnpm store是全局复用的，但node_modules符号链接仍按工作树隔离，无需额外操作
Docker 构建时，上下文必须指向工作树根目录
用 Docker 测试不同分支时，最常踩的坑是构建上下文仍指向主工作区，导致镜像打包了错误分支的代码。Docker 不会自动感知你当前在哪个工作树里，它只认你执行 docker build 时所在的路径。
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
正确流程是：
cd ../myapp-test-branch<br>docker build -f ./Dockerfile -t myapp:test-202607 .
关键点：. 必须是当前工作树的根目录，而不是原始仓库路径。
- 别在主仓库目录下执行
docker build -f ../myapp-test-branch/Dockerfile—— 这会让构建上下文包含整个父目录，可能泄露无关文件 - 配合
.dockerignore使用，确保忽略.git、node_modules、.env等（这些在工作树里存在，但不应进镜像） - CI 脚本中若动态生成工作树，务必用
realpath或pwd显式确认构建路径，避免硬编码路径出错
清理残留工作树前，先检查是否有未提交更改
git worktree remove 不会检查工作树内是否有未 git add 或未 commit 的修改，默认直接删目录。一旦误删，本地改动就永久丢失，Git 不会警告。
安全删除三步走：
- 进入该工作树目录，运行
git status确认无未跟踪/已修改文件 - 回到主仓库目录，用
git worktree list核对路径是否准确（注意输出中的 tab 分隔） - 执行
git worktree remove ../myapp-test-branch，不是rm -rf
真正容易被忽略的是：VS Code 可能仍在后台监听该目录的文件变更，关掉对应窗口再删更稳妥。另外，某些 CI 工具（如 GitHub Actions）临时创建工作树后没清理，会导致磁盘占满——建议所有自动化脚本末尾加 git worktree prune。
