git分支与dev/test/prod环境必须一一硬绑定：dev环境只部署dev分支，test环境部署pr关联的test/或pr-分支，prod环境仅接受main分支带语义化版本号（如v1.2.0）的tag推送，确保ci/cd可预测。
Git 分支如何与 Dev/Test/Prod 环境一一对应
分支和环境必须硬绑定，否则 CI/CD 流水线会失去可预测性。常见错误是把 main 直接部署到所有环境，或让 dev 分支在多个环境轮换使用。
正确做法是每个环境只接受一个固定分支的推送：
-
dev环境只部署dev分支（或按需为每个 feature 创建临时环境，如feature/login→env-feature-login） -
test环境只部署 PR 关联的test/*分支或自动合成的预合并分支（如pr-123） -
prod环境只接受来自main的 tag 推送，且必须带语义化版本号（v1.2.0），不能直接部署main的 latest commit
Azure DevCenter 和 GitOps 工具（如 Argo CD）都依赖这种单向映射。一旦分支混用，就会出现“测试通过但上线失败”——因为 test 环境跑的是 test 分支，而 prod 部署的是 main，两者 diff 被漏掉了。
CI/CD 流水线怎么触发才不丢变更
关键不是“谁触发”，而是“触发源是否包含完整上下文”。很多团队用 push 到 main 触发 prod 部署，结果发现某些配置变更没进流水线——因为那些变更只提交到了 config 仓库，或只改了 kustomize overlay 目录，没碰应用代码。
推荐组合触发方式：
- 主代码仓库
push到main→ 触发镜像构建 + 部署到 staging - 配置仓库（如
infra-config）push到main→ 触发 Kustomize overlay 更新 + 同步到所有环境 - 打 tag（
v*）→ 触发 prod 部署 + 自动创建 GitHub Release
注意：pull_request 事件必须带上 base 分支信息，否则无法判断该 PR 应该部署到哪个 test 环境。GitHub Actions 中要用 ${{ github.base_ref }}，而不是硬编码 test。
git-flo 或类似工具如何避免分支命名污染
工具本身不解决规范问题，只放大已有规则。如果团队没约定 feature/xxx、release/v1.2 这类前缀，gf branch 就会生成一堆无意义的 abc123 分支，CI 脚本根本没法路由。
真正起作用的是三件事：
- Git 钩子（
pre-push）校验分支名是否匹配正则^(feature|bugfix|release|hotfix)/[a-z0-9-]+$ - CI 脚本里用
${{ github.head_ref }}提取前缀，决定部署路径（如feature/→ dev 环境，release/→ staging） - 删除远程分支后，自动清理对应环境（比如删掉
feature/auth，就调用 API 销毁env-feature-auth）
没这三层，再好的工具也只会让分支越积越多，最后 git branch -r | wc -l 超过 200 个。
Docker 构建时怎么保证工作树状态可信
最常踩的坑：本地 git status 显示干净，但 docker build 仍打包了未提交的调试代码。这是因为 COPY . /app 复制的是文件系统快照，不是 Git 提交快照。
安全做法只有两个：
- CI 流水线中强制用
git clone --depth 1 --branch $BRANCH --single-branch，确保构建上下文只含已提交内容 - 本地开发时，用
git worktree隔离不同分支，然后docker build -f Dockerfile --build-arg GIT_COMMIT=$(git rev-parse HEAD) -t myapp:$GIT_COMMIT .
别信 .dockerignore 能拦住所有脏数据——它不处理已暂存但未提交的修改，也不防 symbolic link 指向外部目录。唯一可靠的事实源，永远是 git rev-parse HEAD 对应的 tree。
