上线前是否需测试master分支？Git Flow流程下的分支测试疑问

一、别跳过Release分支，它就是预测试的关键 #

Git Flow本身就设计了Release分支来解决你这个问题，很多人图省事直接从develop合到master，刚好踩了这个坑。正确的流程应该是：

• 当develop完成用户验收和基础测试后，从develop拉出一个release/vx.x.x分支（比如release/v1.2.0）
• 这个分支专门做上线前的最终兜底验证：比如适配生产环境的配置测试、核心业务流程回归、边缘场景校验，甚至可以在类生产的staging环境跑全量测试
• 要是发现小bug，直接在release分支上改，改完同步回develop和后续要合并的master分支
• 等所有验证通过，再把release分支合并到master并打上线标签，同时把修复内容合并回develop，避免后续版本丢代码

二、如果直接合到Master，这些测试步骤不能少 #

要是你暂时不想改流程，直接合到master后必须做这些验证：

• 立即跑镜像级测试：合并后马上构建生产环境用的镜像，部署到和生产完全一致的隔离测试环境，跑全量自动化回归测试，没问题再推生产
• 核心流程冒烟测试：针对登录、支付这类核心路径写自动化用例，合并到master后自动触发，用例不通过直接阻断上线
• 灰度发布试错：把master的代码先放10%的流量到生产，盯着监控看错误率、响应时间、业务指标，稳定个10-30分钟再全量发布，出问题直接切回旧版本

三、用CI/CD把测试规则焊死 #

给master分支加硬约束，从流程上避免人为疏漏：

• 开分支保护：禁止直接往master push代码，必须通过PR合并，而且PR必须满足两个条件：自动化测试（单元、集成、E2E）全过，至少一个同事审核通过
• 合并后自动触发流水线：构建镜像 → 部署staging环境 → 跑全量测试 → 测试通过才允许部署生产，中间任何一步失败都打回
• 加监控告警：master分支部署到生产后，实时监控错误日志、业务指标，一旦出现异常（比如错误率超过0.1%）立刻发告警，方便快速回滚

四、成熟的配套模式 #

• Git Flow标准流程：就是上面说的用Release分支做中间验证，这是Git Flow设计的初衷，专门解决develop到master的过渡测试问题
• 蓝绿/金丝雀发布：和master分支验证结合，即使合并后出问题，也能在几秒内切回旧版本，把用户影响降到最小
• 测试左移：在develop阶段就把大部分测试做足，比如单元测试覆盖率拉到80%以上，集成测试覆盖核心链路，前置测试越充分，master分支出问题的概率就越低

内容的提问来源于stack exchange，提问作者Aldo Inácio da Silva