审批 / 批准：什么是它们，Git 中的 approval 和 code review

什么是 pull request 审批

审批（approval）— 是对 pull request 的积极评审，意味着审查人已检查代码，未发现严重问题，并认为变更已准备好合并。在 GitHub 界面中，这是 PR 页面上的绿色“Approve”按钮。审批后，作者（或任何具有写入权限的参与者）可以执行 merge。

审批过程是 Branch Protection Rules 的一部分。仓库所有者配置必要要求：最少审批次数（例如 1 或 2），谁可以审批（代码所有者、团队成员），以及 PR 在变更后是否需要重新审批（Dismiss stale reviews）。如果没有配置规则，审批是可选步骤，但在专业团队中它是必须的。

GitLab 使用类似的机制，名为 Approval Rules。在 GitLab 中，您可以配置不同组存在多少审批（例如，后端开发人员 2 个和 DevOps 1 个）。在接受所有必要审批后，PR 将在 CI/CD 管道为绿色的条件下自动解锁以进行 merge。

审查类型：Approve、Request Changes、Comment

在 GitHub 和 GitLab 中，审查人可以在 pull request 上留下 三种类型的审查。每种类型对合并过程有不同的状态和影响。Approve — 绿色，Request Changes — 红色，Comment — 中性灰色。类型的选择取决于代码质量和变更的接受准备就绪。

Approve — 审查人确认：代码编写正确，符合标准，没有明显错误，可以合并。Approve 并不意味着代码是理想的 — 只是说它足够好以投入生产。如果有小的意见（风格、命名），可以作为评论留下，而不必锁定 PR。

Request Changes — 审查人发现在 merge 之前必须解决的问题：逻辑错误、漏洞、架构违反、缺少测试。在 Request Changes 之后，PR 被锁定，需要同一审查人的重新审批才能解锁（如果在新的提交中启用了 Dismiss stale reviews 选项）。

• Approve — 代码准备好合并，可以在 CI 通过后 merge。
• Request Changes — 必要的修复，PR 被锁定直到重新审查。
• Comment — 不锁定 PR 的一般意见或建议。

在仓库中配置审批规则

Branch Protection Rules — 是 GitHub 的合并质量控制机制。在 Settings → Branches 中为每个受保护分支（main、develop、release/*）进行配置。主要参数：必要审批次数、代码所有者（CODEOWNERS）、必要的 CI/CD 检查以及禁止没有 PR 的 push。

Dismiss stale pull request approvals 参数 — 如果向 PR 添加了新的提交，则自动移除审批。这确保审查人审批的是将被合并的精确代码版本。如果没有这个设置，作者可以在审批后添加新代码，它将在没有重新检查的情况下进入 main。

CODEOWNERS — 仓库根目录中的文件，指定不同目录的责任人。如果 PR 涉及属于某代码所有者的文件，则他的审批成为必要。CODEOWNERS 分配责任区域：iOS 开发人员负责 Swift 文件，DevOps 负责 Docker 配置，测试人员负责测试场景。

# 仓库根目录中的示例 CODEOWNERS 文件

# iOS 开发人员拥有 Swift 代码
*.swift @team/ios-developers

# DevOps 拥有 CI/CD 配置
.github/workflows/* @devops-team

# QA 工程师审查测试
**/tests/* @qa-engineers

# 其他所有内容的默认所有者
* @tech-leads

审批前的 code review：检查什么

Code review 在审批之前 — 是系统性地检查代码，而不是表面地看 diff。高质量的 code review 包括检查架构、逻辑、风格、测试和安全。没有这种检查，审批就成为了一种形式，而不是质量控制工具。

首先检查什么：变更的逻辑 — 代码是否解决了给定的任务，是否有副作用，边界情况的处理是否正确。测试 — 新的测试是否覆盖了所有场景，现有的测试在变更后是否通过。安全 — 是否存在 SQL 注入、XSS、敏感数据泄露。

什么不应该成为审查的内容：格式化风格（这有 linter 和 formatter），事先做出的架构决定（它们在编写代码之前已讨论）。如果审查超过 400 行或而而超过一小时 — 这表明任务太大并需要分解。审查的最佳实践是在 PR 创建后 24 小时内审查 200–400 行的片段。

• 逻辑 — 任务解决方案的正确性、错误处理、边界情况。
• 测试 — 新场景的覆盖率、现有测试的通过率、没有不稳定测试。
• 安全 — 没有注入、输出转义、数据访问。
• 性能 — 算法的效率、多余查询、内存泄露。
• 文档 — 文档是否更新，复杂部分的注释是否清晰。

团队中的审批工作流程

在 5–10 名开发人员的团队中，带有审批的典型工作流程如下：开发人员创建 PR，指定审查人（通常是团队中的 1–2 人或代码所有者），CI/CD 启动自动检查。在接受所有必要审批并且 CI 为绿色后，作者执行 merge。从 PR 创建到 merge 的时间平均从 2 小时到 2 天，具体取决于复杂程度。

GitHub Actions 允许在审批后 自动化 merge。如果分支规则已配置，GitHub 会自动锁定 merge，直到所有条件都满足。一些团队使用 bors-ng 或 Mergify — 这些机器人在接受所有审批并通过 CI 后自动合并 PR。这加快了过程，并在 merge 时消除了人为因素。

现代方法是 trunk-based development，使用短命分支。在这种工作流程中，审批必须在几个小时内完成，否则任务将被视为过时并需要与 main 重新同步。具有高水平审查文化的团队力争审批时间不超过 4 个工作小时。

审批中的错误及如何避免

最常见的错误 — 没有真正检查代码的形式审批。当 PR 很大或截止日期快到时，审查人可能会不深入变更而直接点击 Approve。这会败坏整个 code review 过程。解决方案：设置 PR 大小限制（不超过 400 行），并使用代码分析工具（SonarQube、CodeClimate）进行自动检查。

第二个错误 — 过于严格的审批。期望理想的代码会阻碍开发。审查人有时会要求修复不影响质量的风格意见。解决方案：清晰地区分必要意见（锁定）和可选建议（评论）。GitHub 允许明确指出评论是否具有锁定性。

第三个错误 — 没有检查 CI/CD 就进行审批。即使代码看起来正确，它可能无法编译或通过测试。配置的 Branch Protection 会在 CI 为红色时自动锁定 merge，但一些团队为了速度而关闭这种保护。解决方案：始终在审批前检查 CI 状态，绝不审批具有红色管道的 PR。

• 形式审批 — 缺乏真正的代码检查。解决方案：每个 PR 限制 400 行。
• 过于严格 — 因风格意见而锁定。解决方案：区分 blocking 和 optional。
• 忽视 CI — 在红色管道时审批。解决方案：始终检查检查状态。
• 指定作者 — 来自 PR 作者的审批。解决方案：配置 Branch Protection 防止作者审批。