develop分支不能直接发布到测试环境，因其混有未完成功能、未验证代码等不稳定内容；正确做法是从develop创建带版本号的独立test分支（如test/v2.3.0），仅允许修复阻塞性bug，禁止merge新feature，并通过diff校验配置差异后才合并至release。
develop 分支不能直接发布到测试环境
很多团队误以为把 develop 分支推到测试服务器就算“发布测试”，但实际会出问题：该分支可能混入未完成的 feature、未合入的 hotfix，或刚 merge 进来但没验证过的代码。测试环境需要的是**可重复、可追溯、经过集成验证的快照**，不是开发流水线的实时状态。
正确做法是：从 develop 创建独立的 test 分支（如 git checkout -b test/v2.3.0 develop），打上明确标签（如 v2.3.0-test1），再部署。这样 QA 测试时知道基线在哪，出问题也能快速比对变更范围。
-
test分支一旦创建，原则上只允许修复阻塞性 bug（通过 cherry-pick 或小范围 rebase） - 禁止在
test分支上 merge 新 feature，否则测试结果失效 - 每次提测前必须确保
test分支已同步最新 CI 构建产物（而非仅 git commit）
test 分支合并进 release 时必须做 diff 校验
从 test 到 release 不是简单 git merge 就完事。常见错误是直接 push 到 release，结果把测试环境里临时加的日志、mock 配置、debug 工具一起带上线。
真正要检查的是：两分支间实际交付的二进制产物差异、配置文件变更、CI 流水线触发条件是否一致。命令行可快速验证：
git diff --name-only test/v2.3.0 release/v2.3.0 | grep -E "\.(yaml|yml|json|conf|properties)$"
如果输出非空，说明配置有差异，必须人工确认是否应纳入预发。
- 禁止用
git merge --no-ff直接合入release—— 容易掩盖冲突细节 - 建议用
git checkout release/v2.3.0 && git reset --hard test/v2.3.0强制对齐（前提是 release 分支无其他并行修改） - CI 流水线应在
release构建阶段自动校验git describe --tags输出是否匹配预期版本号
hotfix 分支必须同时更新 develop 和 master，但顺序不能错
线上发现 bug 后，从 master 拉 hotfix/xxx 是标准动作，但很多人忘了：这个修复不仅要上生产，还得回流到开发主线。漏掉 develop 会导致下次发版又带出同样问题。
关键约束在于顺序：先合入 master，再合入 develop。如果反过来，develop 里可能已有基于旧逻辑的 feature，强行 merge 会引入不可预测的冲突或行为偏移。
- 合入
master后立即打 tag，如v2.2.1-hotfix1 - 合入
develop前，先git checkout develop && git pull确保基线最新 - 用
git cherry-pick而非merge更安全，避免把 hotfix 分支的无关 commit 带进来
测试分支发布失败后，不能直接重推同名分支
当 test/v2.3.0 部署失败或被 QA 拒收，常见错误是删掉远程分支再重新 git push --force。这会破坏 Git reflog、CI 缓存和依赖该 commit 的 PR 记录。
正确做法是保留原分支，基于它新建修正分支，例如 test/v2.3.0-fix1，并在 PR 描述中注明与前次的差异点（比如 “修复 config.yml 中 database.url 缺失”）。
- 所有测试分支命名必须含版本号，禁用
test/latest这类模糊别名 - CI 系统应对
test/*分支自动归档构建日志，保留至少 7 天 - 运维部署脚本应校验分支名是否匹配正则
^test\/v[0-9]+\.[0-9]+\.[0-9]+(-[a-z0-9]+)?$，防止误操作
test 分支被某人直接 push -f，或者 develop 上 merge 了未过单元测试的 PR——这些行为不会报 Git 错误，但会让整个发布流程失去可信基线。
