git分支应与环境解耦：feature/*仅承载开发，release/staging和release/prod作为临时快照，由ci/cd基于tag动态路由部署，禁止长期维护或直推，确保灰度可控、可追溯、可逆。
Git 分支怎么映射到不同环境才不打架
直接用 develop 推测试、master 上生产，多环境并行时必然冲突。关键不是“要不要分支”，而是“每个分支的生命周期是否与环境解耦”。飞流Flow 的 feature/* + release/staging + release/prod 模型之所以有效，是因为它把环境发布行为从“分支命名”里抽出来，变成独立的、可重入的操作。
常见错误是把 staging 当成长期维护分支——结果每次合入都得处理一堆无关功能的冲突；或者让 feature 分支直推 prod，绕过环境验证。这等于把灰度逻辑写死在分支名里，失去动态控制能力。
-
feature/xxx只负责开发完成，不承载环境语义，合并进哪个release/*由发布策略决定 -
release/staging是临时快照，每次构建后自动打 tag（如staging-v1.2.0-20260617-abc123），不接受直接 commit -
release/prod必须基于已通过 staging 的 tag cherry-pick 或 fast-forward 合并，禁止 merge 多个 feature
CI/CD 流水线里如何触发灰度而不是全量上线
灰度不是靠“改分支名”实现的，是靠 CI/CD 阶段的条件判断和部署目标路由。以 GitLab CI 为例，deploy_staging 和 deploy_prod 两个 job 不能只靠 only: - master 区分，必须绑定明确的环境上下文。
容易踩的坑：用 when: manual 控制生产发布，但没限制操作人权限；或在 script 里硬编码 IP 地址，导致 staging 和 prod 配置混用。
- 每个 deploy job 显式声明
environment: name和url，GitLab 会自动记录部署历史和回滚入口 - 灰度比例控制放在部署后环节：比如调用 Ansible Playbook 更新 Nginx upstream 权重，或向服务注册中心推送实例标签
- 禁止在 CI 脚本里执行
git push—— 所有分支变更应由人工 PR 或自动化 Merge Request 触发，避免流水线污染代码历史
Docker 镜像标签怎么设计才能支持灰度回滚
镜像标签不能只用 latest 或简单版本号（如 v1.2）。灰度失败时你要能精确还原到“上一个通过 staging 的镜像”，而不是猜哪个 commit 对应哪个运行态。
典型反例：CI 构建时用 $(git rev-parse --short HEAD) 打标，结果 staging 和 prod 用的都是同一个 short-hash，根本分不清哪个是验证过的。
- 推荐格式：
{env}-{git-tag-or-sha}-{timestamp}，例如staging-v1.2.0-abc123-202606171422 - 生产环境只允许拉取带
prod-前缀且通过 staging 验证的镜像（可通过 Harbor webhook 或 CI 中校验 registry manifest annotation 实现） - 回滚操作本质是更新 Kubernetes Deployment 的
image字段或 Docker Compose 的image值，不是删掉旧镜像——旧镜像必须保留至少 7 天
模板类服务（如 gitignore.io）灰度时怎么隔离数据变更
这类服务的核心风险不在代码，而在模板内容本身。一次模板更新可能影响所有用户生成的 .gitignore 文件，但又不能停服更新。
很多人试图用分支管理模板文件，结果发现 git checkout 切换模板目录会导致服务中断，或者并发加载时读到半新半旧的数据。
- 模板目录必须挂载为只读 volume，运行时不可写；更新走单独的
template-syncjob，下载后原子替换整个目录（如用rsync --delete+mv替换符号链接） - 模板加载器（如
TemplateController.swift）需支持热重载：监听目录 mtime 变化，重新解析order.json和模板文件，不重启进程 - 灰度期间，新模板只对特定请求头（如
X-Env: staging）生效，生产流量继续走旧模板缓存，直到确认无误再全局切换
真正难的不是设计分支模型，而是让每个环境的构建产物、部署动作、数据变更都具备可追溯、可锁定、可逆的粒度。一旦某个环节（比如镜像 tag 生成、模板加载、流量切分）失去原子性，灰度就退化成赌徒式上线。
