develop分支不能直接读取production配置，因配置属运行时依赖而非代码逻辑，如数据库地址、api密钥等需环境隔离；应遵循配置与代码分离原则，通过环境变量（如node_env）驱动加载对应配置，并严禁提交含敏感信息的文件（如.env），统一由ci/cd secrets或k8s secret注入。
为什么 develop 分支不能直接读取 production 配置？
因为配置内容本身不是代码逻辑，而是运行时依赖——比如数据库地址、API密钥、超时时间。develop 分支跑在开发环境，连的是 dev-db.example.com；master 分支部署到生产，必须连 prod-db.example.com。如果把生产密钥硬编码进 develop 分支，轻则本地调试失败，重则密钥泄露。
怎么让同一份代码在不同分支加载不同配置？
核心原则：配置与代码分离，环境变量驱动。不推荐在 Git 里存多套配置文件（如 config.dev.yml / config.prod.yml），而应统一用一个入口（如 config.py 或 .env），靠环境变量决定加载哪组值。
-
NODE_ENV=development或ENV=dev→ 加载开发数据库、关闭监控上报、启用 debug 日志 -
NODE_ENV=production或ENV=prod→ 连接真实 Redis、开启 Sentry、禁用源码映射 - CI/CD 流水线中，
develop分支构建时自动注入 dev 环境变量；master分支构建时只允许注入 prod 变量（且禁止从代码中读取）
示例（Python Flask）：
import os
DB_URL = os.getenv("DB_URL", "sqlite:///dev.db")
DEBUG = os.getenv("DEBUG", "false").lower() == "true"
Git 里该不该提交 .env 文件？
不该。所有含敏感信息或环境特有值的文件（.env、secrets.json、application-prod.yml）必须加进 .gitignore。否则：
- 新人克隆即暴露生产密钥
- feature 分支合入 develop 时，可能误带 prod 配置
- CI 构建日志里会打印出明文密码（尤其当
set -x开启时）
替代方案：
- 提供
.env.example提交到 Git，标注每个变量用途和默认值 - CI/CD 中通过 secrets 管理后台注入变量（GitHub Actions 的
secrets，GitLab CI 的variables） - K8s 场景下用
Secret对象挂载，而非写死在镜像里
release 分支测试时配置容易错乱，怎么防？
release 分支本质是“即将上线的 develop 快照”，它应该用准生产配置跑 UAT，但又不能真的连生产库。常见错误是手动改 config.py 后忘记还原，导致合入 develop 时污染主干。
建议：
- 在 CI 脚本中显式指定
--env=uat，由部署工具（如 Ansible、Helm）动态渲染配置模板 - 给 release 分支打标签时，同时记录所用配置版本（如
config@v2.1.0-uat），避免靠人肉核对 - 禁止在 release 分支上直接修改配置文件；所有变更走 config repo 的 PR 流程
最常被忽略的一点：配置差异不只是值不同，还可能是结构不同（比如生产环境启用了 gRPC 代理层，开发环境直连 HTTP）。这类差异必须体现在启动参数或条件编译中，而不是靠分支名做 if 判断。
