直接结论：用 env/dev、env/test、env/prod 环境专用分支实现物理隔离，每个分支仅存对应环境配置文件，禁止混放；main 分支只保留通用模板；ci 必须监听 env/** 分支触发、配置服务器显式指定 spring.cloud.config.label 指向对应分支，且环境分支需受保护、强制 pr+审批+校验。
Git分支怎么分才能让Dev/Test/Prod配置不串？
直接结论：用 env/dev、env/test、env/prod 这类环境专用分支，而不是靠 spring.profiles.active 或变量替换来“假装隔离”。配置文件物理隔离比运行时切换更可靠，尤其在 CI/CD 流水线中避免误部署。
常见错误是把所有环境配置塞进一个 main 分支，靠 CI 脚本里写 if [ "$ENV" = "prod" ]; then cp config-prod.yml ... ——这种逻辑容易漏掉路径拼错、覆盖遗漏、或测试分支误推到生产配置分支。
- 每个环境分支只保留该环境的配置文件（如
env/prod分支下只有myapp-prod.yml和database-prod.tf） - 禁止在环境分支中提交非该环境的配置（CI 可加 Git Hook 检查文件名是否含
-dev/-test/-prod） -
main分支不存任何环境具体配置，只放通用模板、模块定义和 README - 环境分支必须受保护：禁止 force push，合并需至少 1 人批准 + CI 通过（比如
terraform validate+yaml-lint）
Spring Cloud Config 的配置仓库该用 branch 还是 profile？
答案是：用 spring.cloud.config.label 指向分支，别依赖 spring.cloud.config.profile 去匹配文件名。前者可控，后者易被应用侧覆盖或忽略。
例如，你设 spring.cloud.config.label=env/prod，Config Server 就只拉取 env/prod 分支内容；而如果只设 spring.profiles.active=prod，但 Config Server 的 label 还是 main，它就会去 main 分支找 myapp-prod.yml ——一旦这个文件被删或改名，服务启动就失败。
- 配置服务器启动参数必须显式指定
spring.cloud.config.label，不能依赖默认值master -
application.yml中的spring.profiles.active只影响应用加载哪些本地 profile，不影响 Config Server 拉哪份远程配置 - 分支名要带前缀（如
env/），避免和功能分支（feature/、hotfix/）混淆，也方便 CI 过滤 - Terraform 等 IaC 工具同理：用
branch参数指定模块源，而不是靠变量动态拼接路径
为什么 env/test 分支改了，CI 却没触发对应环境部署？
根本原因通常是 CI 配置里没监听环境分支的 push 事件，或者 pipeline 定义里硬编码了分支名（比如只监听 main 或 develop）。
典型陷阱是把部署逻辑写死在 .gitlab-ci.yml 的 only: 或 GitHub Actions 的 on.push.branches: 里，漏掉了 env/ 前缀分支。
- GitLab CI 示例：用
rules:匹配分支名，而不是only:（已废弃） - GitHub Actions 示例：写
on: push: branches: ['env/**']，不是['main', 'develop'] - 每个环境分支应有独立的 job，且 job 名称/标签要体现环境（如
deploy-to-test），避免复用同一 job 但靠变量区分 - 敏感操作（如 prod 部署）必须加 manual approval，不能仅靠分支名自动触发
多人同时改 env/prod 分支，怎么防止配置冲突？
靠代码评审（PR）+ 分支保护 + 配置格式校验，而不是靠“大家自觉不碰”。IaC 配置不是普通代码，一次 YAML 缩进错误可能导致整个集群重建。
真实场景中，env/prod 分支的每次变更都应视为高风险操作，流程上必须卡点。
- 开启分支保护：禁止直接 push，必须走 PR；要求 status check 通过（如
terraform validate、yamllint、checkov） - PR 模板强制填写变更原因、影响范围、回滚步骤（哪怕只是改了个超时时间）
- 对 Terraform 等状态敏感工具，PR 中必须附
terraform plan输出（可由 bot 自动生成并评论） - 避免在
env/prod分支上做长周期开发；新配置先提env/test，验证后再 cherry-pick 或 rebase 到 prod
