git多分支合并后不能直接上线，因merge仅解决代码冲突，不处理环境差异、配置漂移与依赖错位；production分支应只接受staging验证过的commit hash，推荐用git tag标记灰度版本，强制--no-ff merge便于追溯，nginx结合commit hash实现轻量灰度，回滚需解耦部署与git状态，依赖原子ln -sfn及可逆migration验证。
Git 多分支合并后直接上线，等于把开发、测试、预发环境的不确定性全扔给生产环境。灰度发布不是加个开关那么简单，关键在「合并后如何控制流量分发节奏」和「回滚路径是否真正可用」。
git merge 后，为什么不能直接 push 到 production 分支？
因为 merge 只解决代码冲突，不解决环境差异、配置漂移、依赖版本错位。你看到的 CI 通过，可能只是单元测试跑通；但线上数据库 schema 变更没执行、新旧服务 API 协议不兼容、缓存 key 格式变了——这些都不会在 git merge 时报错。
- production 分支应只接受经过
staging环境验证的 commit hash，而非任意 merge 提交 - 推荐用
git tag（如v1.2.0-rc1）标记可灰度的构建产物，而不是靠分支名判断“是否稳定” - 禁止在 production 分支上做 fast-forward merge，必须用
--no-ff强制生成 merge commit，方便追溯灰度范围
灰度发布的最小可行配置：Nginx + Git commit hash 路由
不依赖复杂发布平台，也能实现基于请求特征的灰度。核心是让 Nginx 根据 header 或 cookie 指向不同部署目录，而目录名对应 Git 的 commit hash。
- 构建阶段生成带 hash 的部署目录：
/var/www/app-$(git rev-parse --short HEAD) - Nginx 配置里用
map提取$http_x_gray_flag，匹配到特定值就重写 root 到对应 hash 目录 - 灰度期间保持两个目录并存（如
app-a1b2c3和app-d4e5f6），避免删旧目录导致 502 - 注意：Nginx 的
root指令不支持变量拼接，必须用alias或提前生成配置文件再 reload
如何确保灰度失败时 30 秒内回滚？
回滚快慢，取决于你是否把「部署状态」和「Git 状态」解耦。不要等运维手动 checkout 旧 commit 再 build —— 那至少 2 分钟起。
- 每次成功部署，自动记录
deploy.log：时间、commit hash、部署目录、健康检查结果 - 写一个极简回滚脚本
rollback.sh，只做三件事：停当前服务、ln -sfn 上一个有效目录、重启 Nginx - 关键点：
ln -sfn是原子操作，比删目录+cp 快 10 倍；且要求所有部署目录命名含完整 hash，不能用时间戳 - 务必测试回滚后数据库 migration 是否可逆——如果新版本加了非空字段，旧代码会直接 crash，这不是发布系统能兜住的
灰度真正的难点不在路由或脚本，而在「哪些变更必须全量、哪些可以切流、哪些压根不该走灰度」。比如数据库 schema 变更、全局配置项修改、第三方 SDK 升级，这些从来就不是靠分流量能验证的。得靠 pre-check 清单和人工确认节点卡住，而不是指望自动化流程替你做判断。
