git worktree支持多分支并行开发，每个工作树拥有独立环境（如node_modules、ide缓存），无需stash或checkout切换，共享.git数据库且路径不可嵌套，删除需用git worktree remove避免残留。
dev/test/pre/pro 分支如何对应到真实部署环境
不是所有叫 dev 的分支都跑在开发机上，也不是所有 test 分支自动部署到测试服务器——映射关系必须显式定义并同步维护。
常见错误是开发者本地切到 test 分支后直接 npm start，结果连的是自己本地 mock 服务，而 CI/CD 流水线却把同名分支部署到了另一套测试集群，导致“本地能过、CI 报错、线上不一致”。
- 每个分支名应有唯一、可查的部署目标：比如
dev→ Kubernetes 命名空间dev-ns，test→test-cluster-01 - CI 脚本中必须硬编码或从配置中心读取该映射，不能靠分支名字符串模糊匹配（例如避免用
if branch contains "test"这类逻辑） - 推荐做法：在项目根目录放一个
.env.deploy文件，内容如DEPLOY_TARGET=test-cluster-01，CI 读取它而非解析分支名
标签（tag）和分支（branch）在上线流程中的分工边界
git tag 不是分支的替代品，也不是“打个标记就完事”。它的核心作用是锁定不可变的构建产物版本，而分支负责承载可变的集成过程。
典型误用：在 pre 分支上反复 push，然后打 v1.2.3-rc 标签；下次再改再 push，又打同名标签——Git 允许覆盖，但 CI/CD 工具可能缓存旧构建，导致上线版本和标签名不符。
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
- 标签必须指向一次成功的 CI 构建产物（如 Docker 镜像 SHA 或 tar 包 checksum），而非仅 commit hash
- 上线操作应基于标签拉取制品，而不是 checkout 分支再构建（否则环境差异会导致“构建非所测”）
- 禁止对同一语义版本重复打 tag，如
v1.2.3-rc只能存在一个，后续修正必须升版为v1.2.4-rc
GitHub Actions 中用 matrix 实现跨环境一致性验证
光靠人工保证 dev 和 test 分支走同一套 CI 脚本没用，真正要验证的是：同一份代码，在不同环境配置下是否行为一致。
比如 dev 环境用 SQLite，test 环境用 PostgreSQL，数据库迁移脚本在 dev 跑过，未必能在 test 过——这种差异必须被自动化捕获。
- 在
.github/workflows/ci.yml中定义 matrix，变量包括env（值为["dev", "test", "pre"]）和db（值为["sqlite", "pg"]） - 每个 job 用
runs-on指定对应环境 runner，并通过env:注入DB_TYPE: ${{ matrix.db }} - 关键点：所有 matrix job 必须共享同一个 commit，且共用同一套 artifact 缓存，避免因构建时间差引入隐性变量
为什么 git worktree 比频繁 checkout 更适合多环境并行
当你需要同时调试 dev 上的新功能、验证 pre 上的灰度配置、回滚检查 pro 的某次发布，git checkout 切换会污染 node_modules、重编译、重加载 VS Code 插件，效率断崖下跌。
而 git worktree 是真正的隔离：每个工作树拥有独立的 node_modules、.git/index、IDE 缓存，且不共享 Git 索引锁。
- 创建命令：
git worktree add ../my-project-dev dev、git worktree add ../my-project-pre pre - 注意：worktree 路径不能嵌套在主仓库内，否则 Git 会拒绝（避免递归陷阱）
- 删除前必须先
git worktree remove，直接rm -rf会残留 .git/worktrees 记录，下次git worktree list仍显示已失效路径
