github.com/google/syzkaller@v0.0.0-20251211124644-a066d2bc4b02/docs/translations/zh_CN/maintaining.md (about)

     1  > [!WARNING]
     2  >
     3  > **请注意，这是社区驱动的官方 syzkaller 文档翻译。当前文档的最新版本（英文版）可在 [docs/maintaining.md](/docs/maintaining.md) 中找到。**
     4  
     5  # 维护者指南
     6  
     7  ## 线性历史
     8  
     9  我们保持线性历史记录，并在仓库设置中禁用合并提交（merge commit）。
    10  拉取请求（PR）仅有两个选项：
    11  - **变基合并（Rebase and merge）**\
    12    若 PR 中的所有提交已妥善整理/修复，优先选择此方式，
    13    因其保留 PR 中的提交记录（将 PR 中的所有提交直接添加至 master 分支的最新提交之上）。
    14  - **压缩合并（Squash and merge）**\
    15    若 PR 包含分散的修正提交或提交组织混乱时优先选择此方式
    16    （将 PR 中的所有提交压缩为单个提交并添加至 master 分支的最新提交之上，同时允许编辑提交主题/描述）。
    17  
    18  ## PR 检查 (CI)
    19  
    20  合并前需通过 `cla/google` 检查。
    21  
    22  合并前通常需通过所有 CI 测试。\
    23  例外情况包括基础设施偶发问题（尤其是外部服务：`codecov`、`ci/fuzzit`）
    24  以及偶现的超时/内存溢出（但若 PR 本身显著增加此类问题频率则不可豁免）。所有静态检查警告和测试错误均视为严重问题。
    25  
    26  ## 测试
    27  
    28  原则上鼓励为新代码和错误修复添加测试。应要求贡献者补充测试。
    29  
    30  但不同代码的测试难度存在差异。
    31  以下情况更易添加测试（建议补充）：无外部依赖的抽象功能（如解析器、数据转换、计算逻辑）；已有成熟测试基础设施的代码（添加新测试仅需遵循现有模式）。
    32  以下情况测试难度较高（可不强制要求，但仍欢迎补充）：存在难以模拟的外部依赖的代码（qemu、内核、镜像等）；缺乏现成测试基础设施，需先构建整套框架才能添加测试的代码。
    33  
    34  ## 善用判断力
    35  
    36  当前暂无严格的审查/所有权规则，请灵活运用判断力。
    37  
    38  若您负责项目的特定领域（如某操作系统的支持），可自行合并变更而无需额外审查（尤其小型变更且 CI 通过时）。
    39  亦可审查并合并项目其他部分的变更。若信心不足或需要额外意见，请与其他维护者协同处理。