维护者指南

线性历史

我们保持线性历史记录，并在仓库设置中禁用合并提交（merge commit）。
拉取请求（PR）仅有两个选项：

• 变基合并（Rebase and merge）
  若 PR 中的所有提交已妥善整理/修复，优先选择此方式， 因其保留 PR 中的提交记录（将 PR 中的所有提交直接添加至 master 分支的最新提交之上）。
• 压缩合并（Squash and merge）
  若 PR 包含分散的修正提交或提交组织混乱时优先选择此方式 （将 PR 中的所有提交压缩为单个提交并添加至 master 分支的最新提交之上，同时允许编辑提交主题/描述）。

PR 检查 (CI)

合并前需通过 cla/google 检查。

合并前通常需通过所有 CI 测试。
例外情况包括基础设施偶发问题（尤其是外部服务：codecov、ci/fuzzit） 以及偶现的超时/内存溢出（但若 PR 本身显著增加此类问题频率则不可豁免）。所有静态检查警告和测试错误均视为严重问题。

测试

原则上鼓励为新代码和错误修复添加测试。应要求贡献者补充测试。

但不同代码的测试难度存在差异。 以下情况更易添加测试（建议补充）：无外部依赖的抽象功能（如解析器、数据转换、计算逻辑）；已有成熟测试基础设施的代码（添加新测试仅需遵循现有模式）。 以下情况测试难度较高（可不强制要求，但仍欢迎补充）：存在难以模拟的外部依赖（qemu、内核、镜像等）；缺乏现成测试基础设施，需先构建整套框架才能添加测试的代码。

善用判断力

当前暂无严格的审查/所有权规则，请灵活运用判断力。

若您负责项目的特定领域（如某操作系统的支持），可自行合并变更而无需额外审查（尤其小型变更且 CI 通过时）。 亦可审查并合并项目其他部分的变更。若信心不足或需要额外意见，请与其他维护者协同处理。