Git分支回滚和测试提测流

2022年1月记录，分类「Git」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。

问题现场

这篇是一次提测混乱后的整理。那次多个需求共用测试环境，分支被来回合并，最后谁的代码进了环境都说不清，所以我把提测、验证、回滚做成了固定动作。

整理时我特意把输入、动作、观察点和风险拆开，方便后面补用例。

分支约定

• 提测单必须写明 commit、配置变更、数据库脚本和影响模块。
• 测试环境只接受 release 或 feature 分支，不直接从个人分支部署。
• 回滚不是只回代码，还要检查配置、缓存、定时任务和数据库兼容。

git log --oneline --decorate -5
git diff --name-only origin/main...HEAD
git tag qa-20220122-order-fix

测试动作

• 测试开始前能确认当前环境版本。
• 缺陷回归时能定位修复 commit。
• 发布失败时有明确的回滚入口和验证清单。

我一般会把这部分同步到缺陷模板里，让开发能直接看到复现材料和判断依据。

后来保留下来的规则

Git 流程看起来是开发习惯，实际会直接影响测试结论是否可信。版本不清楚的时候，测得越多越乱。这个记录后续还可以继续补真实缺陷样本，让它从笔记变成团队检查清单。