GitHub Code Coverage merge protection：先定义上线契约，再选择百分比

Dev
GitHub 可将 coverage 和 code quality 阈值作为 PR 合并保护。设置 80% 之前，团队应先定义 baseline、diff coverage、例外和 rollout。
好的 coverage gate 不是神奇数字，而是让高风险变更可解释的运行契约。

发生了什么

GitHub 在 2026 年 6 月 30 日宣布，GitHub Code Coverage 可用于 pull request merge protection。当 PR 未达到 coverage 或 code quality 阈值时，可以阻止合并。

为什么重要

关键变化是 coverage 信号进入 review、ruleset 和 branch protection，而不只是外部 dashboard。

社区信号

开发者社区长期争论 coverage threshold：高覆盖率不等于高质量，但放任覆盖率下降会形成测试债务。

运维影响

实践中应区分 total coverage 和 diff coverage。前者描述长期健康度，后者关注本次 PR 是否增加未测试代码。

检查清单

建议先 soft fail，保存 main branch baseline，明确排除 generated code 和 migrations，并指定谁可以批准 coverage 下降。

风险

风险是虚假的安全感和变慢的 CI。coverage gate 只能补充好的 assertions、integration tests 和人工 review，不能替代它们。

Rollout checklist

• Start with a baseline, not an ideal target.

• Separate total coverage from diff coverage.

• Document exclusions and exception approvers.

• Use soft fail before hard enforcement.

来源

다른 글