GitHub Rulesets 与仓库治理
一次未经评审的提交进入 main 后，团队通常先问“是谁合并的”，随后才发现更难的问题：管理员默认可以绕过旧保护规则，机器人使用个人 PAT，Required check 的名称早已漂移，组织规则与仓库规则还在叠加。页面上的绿色勾选只能证明有人保存过配置，不能证明普通成员、管理员和自动化身份都走在预期路径上。
GitHub 仓库治理真正控制的是“谁可以让什么提交以什么证据更新关键引用”。仓库角色决定谁能读、分诊、写入、维护和管理；Rulesets 与传统 branch protection 决定分支或 tag 必须满足哪些条件；bypass 决定例外身份怎样留下痕迹；Rule Insights 与组织 Audit Log 则回答规则何时通过、失败、被绕过或被修改。
先建立一个归属于测试组织的非生产仓库，默认分支设为 main。个人仓库足以练习单仓 Ruleset，但组织角色、团队、组织级规则和组织审计需要组织仓库才能形成完整闭环。GitHub Enterprise Server 的规则、API 和界面与实例版本绑定，操作时应切换到对应版本文档，不能直接套用 GitHub.com 的最新界面。
至少准备以下身份：
一个仓库管理员，用于创建规则，但不承担普通成员验证。一个具备 Write 的普通成员，用于验证直推和未满足门禁的合并确实失败。一个评审者或 owner，用于产生有效批准。
若仓库有机器人，再准备一个 GitHub App 或专用自动化身份，不复用个人 PAT。
开发机安装 Git；可选安装 GitHub CLI。先确认 CLI 登录到了测试主机和预期账号：
git --version
gh --version
gh auth status
gh repo view your-org/your-repo --json nameWithOwner,defaultBranchRef,visibility不要在生产主线直接试错。Ruleset 的目标模式、required status check 名称或 bypass 配置错误，都可能让正常贡献者停摆，或反过来留下未保护分支。先在测试仓库完成同角色验证，再推广到组织范围。
GitHub 仓库治理是托管控制面，无需在开发机部署服务。单仓入口为 Settings -> Rules -> Rulesets -> New ruleset -> New branch ruleset。组织希望统一多仓基线时，再由组织设置创建 organization ruleset；先验证单仓有助于缩小误配置影响面。
GitHub 的 Rulesets 规则说明给出了当前能力边界：公开仓库可在 GitHub Free 使用 Rulesets，私有仓库需要 GitHub Pro、Team 或 Enterprise Cloud；私有、内部仓库及其 fork network 的 push rulesets 还受套餐和仓库类型约束。套餐页和设置页会变化，选型记录应保存“能力需求、仓库可见性、当前合同”三项，而不是把某个价格或按钮写成长期事实。
创建名为 default-branch-baseline 的 branch ruleset，先做最小配置：
Enforcement status 设为 Active。若当前套餐支持 Evaluate，可先观察而不阻断；不支持时用测试仓库直接 Active。Target branches 选择默认分支，不用含糊的 m* 模式代替明确目标。启用 Restrict deletions 和 Block force pushes。
启用 Require a pull request before merging。要求至少一项有效审批，并启用新提交使陈旧审批失效。启用 Require conversation resolution before merging。
暂不填写不存在的 required status check；等测试检查稳定产生后再加入。初次验证不配置 bypass，或只给一个专用应急团队“仅通过 Pull Request 绕过”。
保存后先查看规则，而不是马上相信配置成功：
gh api repos/your-org/your-repo/rulesets \
--jq '.[] | {id, name, target, enforcement, source_type}'
gh api repos/your-org/your-repo/rules/branches/main \
--jq '.[] | {type, source_type, ruleset_id}'第一条列出仓库可见的 Rulesets；第二条回答 main 当前实际命中的 active rules，包含仓库级和组织级来源。若页面有规则但第二条没有，先检查 enforcement status 和目标模式。
先画清控制层级
一个提交能否进入 main，可能同时受组织 Ruleset、仓库 Ruleset、传统 branch protection、PR 审批、status check 和 actor bypass 影响。Rulesets 没有“仓库级覆盖组织级”的简单优先级；命中的约束会聚合，传统保护规则也可继续叠加。
治理时应把每条规则写成可验证意图。例如“默认分支所有改动经过 PR”对应 Require a pull request；“审批后的代码不能被静默替换”对应 dismiss stale approvals；“任何讨论有结论后再合并”对应 conversation resolution。只保存截图而不记录意图，后续维护者无法判断某个选项能否删除。
Rulesets 与传统保护分支怎样选
传统保护分支仍然有效，也覆盖大量常用门禁；Rulesets 更适合新基线，因为它有命名、启停状态、可见性、多规则叠加、组织范围和 Rule Insights。迁移不需要一次性删除旧保护规则，可以先建立等价 Ruleset，用有效规则 API 和行为实验确认，再逐项退役重复配置。
两者并存期间最容易犯的错误是“我在新规则里设为一项审批，为什么仍要求两项”。原因通常是旧规则或组织规则更严格。排查时查看目标分支的全部有效规则，不要只盯着刚编辑的页面。
传统保护规则在管理员适用范围、匹配行为和签名提交等细节上与 Rulesets 不完全相同。团队应把迁移当作行为变更，不能只做字段对照。
审批、CODEOWNERS 与检查
Require a pull request 只是把变更导入 PR，并不自动要求审批。至少一项审批、Code Owner 审批、新提交撤销旧审批和对话解决需要分别配置。高风险仓库还可要求最后一次可审查 push 由作者以外的人批准，降低作者在批准后追加内容的风险。
CODEOWNERS 是仓库内版本化文件，Ruleset 是仓库外控制面。前者描述路径责任，后者把 owner 批准变成硬门禁。务必让 /.github/CODEOWNERS 自身归仓库治理团队所有，并用 PR 实验验证路径匹配。
Required status checks 只能引用会稳定产生的检查名称。添加前先让检查在普通 PR、Fork PR、文档变更和自动化 PR 等目标场景中运行，确认其名称、来源 App 和完成状态稳定。选择“Require branches to be up to date”会增加重复运行与排队成本；高并发仓库可评估 merge queue，使候选结果基于接近最终主线的合并组验证。
合并历史、签名与引用保护
Require linear history 会阻止 merge commit 进入目标分支，因此仓库必须允许 squash 或 rebase merge。它改善主线可读性和单提交回滚，却会丢失原始分支拓扑；是否启用取决于审计依赖 PR 记录还是 Git 图本身。
Require signed commits 约束进入目标引用的提交验证状态，不等同于 SSH 登录或 DCO。机器人、网页合并、squash 和本地 rebase 都要单独验证。启用前先盘点自动化身份和贡献者签名方式，否则治理上线会变成大面积无法合并。
tag ruleset 适合保护发布 tag 的创建、更新和删除，但 tag 被保护并不能证明制品已经签名，也不能证明部署经过授权。发布链还要把制品身份、环境权限和部署证据连接起来。
合并门禁与部署权限不要混成一个角色
Require deployments to succeed before merging可以要求候选变更先成功部署到指定环境，例如 staging，再允许合并。这条规则消费部署结果，并不授予任何人生产部署权。环境的 required reviewers、可部署分支、secret 可见性和管理员绕过策略仍由 environment 独立控制。
架构上应把代码批准者、规则管理员和生产部署批准者视为三种职责。开发者可以获得 Write 并发起 PR，规则管理员维护 Ruleset，生产批准者只在受保护环境上放行。若同一个宽泛 Admin 团队同时拥有 Ruleset bypass 和环境 bypass，一次账号失陷就能从改代码直达生产，所有绿色门禁都会退化成装饰。
验证时建立一个不会触达真实生产的 governance-staging 环境，让测试 PR 的部署先失败或保持未完成，预期合并被阻断；再产生成功部署，预期该项门禁解除。随后用无环境权限的普通成员尝试批准或启动受保护部署，预期被拒绝。实验结束后删除测试环境规则和临时部署记录，不能把练习 secret 留在仓库或组织设置里。
Bypass 要配置成例外，不是角色福利
Bypass actor 可以是角色、团队或 GitHub App。优先选择具体团队或 App，不要把整个 Write、Maintain 或 Admin 角色永久加入。能用“For pull requests only”就不授予 always bypass，因为前者仍要求建立 PR，留下差异、讨论和绕过轨迹。
每个 bypass 条目应有 owner、适用事故、批准流程、最长有效期和季度复核。应急团队不应同时是日常开发大组；自动化 App 不应因为一次发布失败就获得所有规则的永久绕过。
治理基线必须用“应该失败”和“应该成功”两类实验验证。只看设置页无法证明目标模式、身份和规则叠加正确。
普通成员验证
普通 Write 成员从最新 main 创建分支：
git switch main
git pull --ff-only
git switch -c governance/ruleset-demo
printf "ruleset demo\n" > ruleset-demo.txt
git add ruleset-demo.txt
git commit -m "docs: add ruleset demo"
git push -u origin governance/ruleset-demo
gh pr create --base main --head governance/ruleset-demo \
--title "docs: verify repository rules" \
--body "Temporary change for ruleset verification."在没有审批时，合并应被 Review required 阻断。随后由独立评审者批准，再由作者追加一个修改代码的提交：
printf "second revision\n" >> ruleset-demo.txt
git add ruleset-demo.txt
git commit -m "docs: revise ruleset demo"
git push
gh pr view --json headRefOid,reviewDecision,mergeStateStatus,statusCheckRollup预期是 head SHA 变化，旧批准失效，PR 再次不能合并。重新审批并满足其他规则后，普通合并路径恢复可用。
再用普通成员测试直推：
git switch main
printf "must not enter main directly\n" > direct-push-demo.txt
git add direct-push-demo.txt
git commit -m "test: verify direct push rejection"
git push origin main预期远端拒绝更新。此时本地 main 比远端多一个练习提交，使用下面的安全清理恢复到远端，不把测试提交带入后续分支：
git fetch origin
git switch -c governance/rejected-direct-push
git switch main
git reset --hard origin/main
git branch -D governance/rejected-direct-push这里的 reset --hard 只针对已明确验证、未推送且已用临时分支隔离的测试提交。真实工作区有未提交内容时禁止照抄；先用 git status 确认干净。
管理员与绕过验证
管理员应分别验证两种设计：
管理员不在 bypass list 时，是否同样被 Ruleset 阻断。应急团队被授予“仅通过 PR 绕过”时，是否仍不能直接 push，但能在 PR 中显式 bypass。
执行一次经过批准的测试绕过，填写抽象原因，例如 governance drill。随后进入 Settings -> Rules -> Insights，预期能看到对应 Pass、Fail 和 Bypass 记录，并能展开具体规则。若配置为 always bypass，必须额外证明团队确实接受它可能不经过 PR 的风险。
API 与清理验证
最终导出当前仓库 Ruleset 摘要和 main 的有效规则作为证据：
gh api repos/your-org/your-repo/rulesets > rulesets-snapshot.json
gh api repos/your-org/your-repo/rules/branches/main > main-effective-rules.json导出文件可能包含组织、团队、规则 ID 和内部仓库元数据，不应提交到公开仓库。验证完成后将其保存在受控审计位置或安全删除。
关闭未合并的练习 PR 并清理分支：
gh pr close --delete-branch
git switch main
git pull --ff-only
git branch -D governance/ruleset-demo
rm -f rulesets-snapshot.json main-effective-rules.json从单仓基线扩展到组织基线
先把仓库按风险分类，而不是对所有仓库复制完全相同的门槛。归档、文档、普通服务、共享库、身份与支付等仓库可有不同审批数量和检查集，但默认分支禁止 force push、通过 PR 合入、规则变更可审计通常可以作为共同底线。
组织级 Ruleset 适合表达共同底线，仓库级 Ruleset 负责增加领域约束。因为规则会叠加，仓库规则应只加严格度，不承担“抵消组织规则”的幻想。使用 repository properties 或明确的仓库集合做分组时，要给属性变更本身设置受控权限，否则改一个标签就可能改变治理等级。
推广顺序建议为：测试仓库行为验证，小范围非关键仓库观察，关键仓库启用，最后处理例外。若套餐支持 Evaluate，先用 Insights 找出将被阻断的自动化和开发路径；若不支持，建立明确回滚窗口，保留旧配置快照，并在少量仓库 Active 验证。
把检查作为外部契约接入
Ruleset 只关心检查的身份和结论，不关心 YAML 如何实现。接入任何质量门禁前记录：检查名称、提供它的 GitHub App、触发场景、正常耗时、失败 owner、超时降级和下线步骤。
重命名检查采用双轨迁移：先让新旧名称同时稳定产生，再把新名称加入规则，验证阻断，最后移除旧名称和旧任务。直接先删旧任务会让 required check 永久 Expected；直接先删门禁则留下无保护窗口。
管理自动化身份
依赖更新机器人通常只需创建分支与 PR；同步机器人可能需要特定目标分支；发布应用可能需要创建 tag。为每个 App 单独列出所需 ref、操作和失败处理，不共享个人账号。先让自动化走普通规则，只有无法通过普通路径且业务确实需要时才加入精确 bypass。
Deploy key、PAT 和 GitHub App 的审计身份与权限模型不同。团队优先使用可安装到指定仓库、权限可枚举且令牌短期化的 GitHub App；个人 PAT 不应用作长期组织机器人凭据。
固定仓库生命周期
新仓库创建时应自动进入风险分类、团队授权和组织 Ruleset 范围；转移、改名、可见性变化和归档时重新验证规则。仓库模板能提供 CODEOWNERS、PR 模板和贡献说明，却不能单独证明服务端 Ruleset 已命中。
归档前撤销写入 App、部署密钥和 bypass，确认必要审计证据已导出。删除仓库是另一类高风险操作，应由组织权限与恢复策略控制，不能依赖 branch ruleset 防止。
退出 GitHub 时保住对象关系和证据
平台迁移不能只执行 git clone --mirror。Git 对象和 refs 可以镜像，Pull Request 讨论、review、Rulesets、团队、App 安装、环境、审计事件、Issue 关联和 release 元数据不会自动进入另一平台。先冻结规则变更并导出仓库与组织配置，再镜像代码和 tag，随后重建身份映射、保护规则、检查名称与机器人权限，最后用普通成员重新跑直推失败、未审批合并失败和正常 PR 成功三条路径。
旧平台至少保留只读窗口，直到新平台的 commit 数量、refs、tag、默认分支、LFS 对象、PR/MR 关联和审计查询均达到迁移标准。回退点应是 DNS、Webhook 与写入口切换之前；一旦两边同时接受写入，就必须暂停迁移或建立明确的单向同步，否则两个主线会同时产生合法但无法自动合并的历史。
查看 Ruleset 列表和单条详情：
gh api repos/your-org/your-repo/rulesets \
--jq '.[] | [.id, .name, .target, .enforcement, .source_type] | @tsv'
gh api repos/your-org/your-repo/rulesets/<ruleset-id>查看某个尚不存在的候选分支会命中哪些 active rules，API 同样可以返回匹配结果，便于上线新分支命名规则前检查：
gh api repos/your-org/your-repo/rules/branches/release-v2查看 PR 当前审批和检查，而不只看绿色按钮：
gh pr view <number> \
--json headRefOid,reviewDecision,mergeStateStatus,latestReviews,statusCheckRollup
gh pr checks <number>组织 owner 在 Audit Log 中应重点搜索规则、成员、团队、仓库与凭证相关事件。页面支持 action、actor、repo、created 等限定词；例如按仓库与日期缩小导出范围。组织 Audit Log的在线查询窗口不是无限期；追溯周期更长时，需要定期导出。Enterprise Cloud 还可把事件流式发送到外部存储，接收端要按至少一次投递设计去重、断流告警和访问控制。
变更 Ruleset 前保存 JSON 快照和变更理由；变更后重复普通成员与 bypass 演练。不要把 JSON 导入当作无审查恢复：目标仓库、团队 ID、App 安装和套餐能力变化都可能使导入结果不同。
Ruleset 已启用，但 main 没有被保护
设置页显示 Active，普通成员仍能直推或无审批合并。
调用 repos/your-org/your-repo/rules/branches/main，确认返回的规则类型和 source_type；再核对 target pattern 是否包含 refs/heads/main 对应目标。
目标选择了错误分支、只创建了 tag/push ruleset、规则状态实际为 Disabled，或测试的是未命中的另一个分支。
修正 target，保持测试规则最小化，保存后重新读取有效规则。
普通成员 direct push 被拒绝，未审批 PR 显示明确阻断原因。
配置一项审批，却要求更多审批
仓库 Ruleset 写着 1，合并框要求 2 或更多。
查看 main 的全部有效规则和仓库 /rules 页面，检查组织 Ruleset 与传统 branch protection。
多条命中规则会聚合，相同类型取更严格约束；旧保护规则不会因为创建 Ruleset 自动失效。
先确定期望的最高基线，再有计划地退役重复旧规则。不要临时给管理员 bypass 来掩盖规则叠加。
API、页面合并框和普通成员行为对审批数量给出一致结果。
管理员可以绕过，团队以为管理员也受保护
普通成员被阻断，管理员却能直推或强制合并。
检查 Ruleset bypass list、传统保护规则的管理员适用选项、自定义角色和 CLI 是否使用了管理员合并参数。
传统保护默认绕过语义、显式 Ruleset bypass 或过宽自定义角色造成例外。
从日常管理员角色移除 bypass；应急能力放入独立团队，并优先限制为仅通过 PR 绕过。
日常管理员与普通成员都受阻；应急身份只能按设计路径绕过，Insights 留下 Bypass 记录。
Required check 永远等待
PR 显示 Expected，实际工作流没有同名检查。
比较规则记录的名称、PR statusCheckRollup 和提供检查的 App；检查路径过滤与事件是否覆盖当前 PR 类型。
Job 重命名、App 重装后来源变化、工作流没有触发，或 required check 在加入规则前从未稳定产生。
恢复检查契约，按双轨方式迁移名称。短期解除门禁必须有批准、时限和复测，不要永久删掉整个检查集。
新 PR 能看到检查从 Pending 进入成功或失败，失败时不能合并。
CODEOWNERS 显示了 owner，却不要求 owner 批准
PR 自动请求 owner，但其他普通 reviewer 批准后仍可合并。
区分“自动请求评审”和“Require review from Code Owners”规则，检查 owner 是否具备显式写权限以及路径是否匹配。
只提交了 CODEOWNERS，没有在 Ruleset 或保护规则中启用 owner 审批；或者该路径规则无有效 owner。
启用 Code Owner 审批，保护 CODEOWNERS 文件本身，并为 owner 团队授予最小必要仓库权限。
修改敏感路径时，非 owner 批准不足以合并；有效 owner 批准后该项门禁满足。
自动化突然不能更新分支或 tag
机器人返回 repository rule violations，人工路径正常。
查看失败 actor、目标 ref、Rule Insights 和 App 当前安装权限；确认它是在创建 PR、直接 push 还是创建 tag。
规则推广时遗漏自动化路径，App 被重装导致身份变化，或旧机器人依赖个人 PAT 和管理员权限。
优先让机器人改走 PR；确需 bypass 时只授权具体 App 和目标动作。替换个人凭证并记录 owner。
机器人能完成唯一所需动作，其他分支、规则编辑和仓库管理仍被拒绝。
找不到预期审计事件
团队想复盘规则修改或权限变化，Audit Log 搜不到。
确认查看者是组织 owner，扩大 created 范围，核对事件类别、组织与仓库限定词，再确认事件是否早于平台当前保留窗口。
默认页面时间范围较短、查询条件错误、操作发生在个人仓库，或团队从未做长期导出。
建立定期导出或企业审计流，按仓库和事件类型进入受控日志存储；为 Ruleset 变更另留评审记录和 JSON 快照。
执行一次测试规则变更与测试 bypass，能在约定审计入口按 actor、repo 和时间找到。
GitHub 网页、REST API、HTTPS Git 和 SSH Git 可能经过不同网络路径。企业代理环境下，先分别验证 gh api user、git ls-remote 与浏览器访问。不要为了让 CLI 可用而关闭 TLS 校验，也不要把代理账号密码写入仓库级 .git/config。
规则读取对普通成员相对开放，规则修改需要 Admin 或带 edit repository rules 的自定义角色。把规则编辑授权给治理团队，而不是所有 Maintain 或 Write 成员。组织 owner 权限更大，应启用强认证、定期复核，并避免用于日常开发。
自动化优先使用 GitHub App：权限按仓库和资源类型声明，安装可撤销，installation token 短期有效。GitHub 的 PAT 指南也把 PAT 定位为代表个人访问资源，长期组织集成优先使用 GitHub App。Fine-grained PAT 仅在无法使用 App 的交互场景采用，限定仓库、权限和到期时间；classic PAT 与个人账号机器人是迁移对象。任何凭证都不能出现在 Ruleset JSON、PR 描述、日志截图或 remote URL 中。
组织可以限制 PAT 类型、要求 fine-grained PAT 审批并设置最大有效期。轮换不能只创建新 token，还要更新消费方、验证新 token、撤销旧 token，再从审计入口确认旧凭证不再使用。机器人返回 401 或突然看不到组织仓库时，先检查到期、撤销、SSO 授权和 App 安装范围，不要通过扩大仓库角色掩盖认证故障。
SSO 授权失效、App 安装被暂停或团队成员被移除，会表现为权限突然下降。排查时先确认 actor 身份与组织成员状态，再看规则；不要把认证失败误判成 Ruleset 故障并扩大 bypass。
建立角色与职责分离
Read 用于读取和讨论，Triage 适合管理 Issue/PR 而不写代码，Write 用于日常贡献，Maintain 负责部分仓库管理，Admin 才能管理高风险设置。默认把开发者放在 Write，通过团队授权，而不是逐人加仓库。规则管理员、代码 owner、日常合并者和应急 bypass 审批人应尽量分离。
至少明确四个 owner：仓库业务 owner 决定仓库是否继续存在；规则 owner 维护基线；检查 owner 保证 required check 可用；身份 owner 回收团队、App 和凭证。没有 owner 的规则一旦阻断，团队往往只能求助管理员临时放开。
规则变更也要走变更管理
Ruleset 位于代码仓库之外，普通 PR 无法天然审批它。团队可采用治理仓库存放期望 JSON、变更说明和验证证据，再由受控身份应用；即使暂时手工配置，也应先评审变更单，保存前后快照，记录操作者，并执行普通成员和应急身份复测。
高风险修改包括降低审批数、删除检查、扩展 bypass、允许 force push、放开分支匹配和改变仓库可见性。这些操作应有双人确认和明确回滚。新增更严格门禁也有可用性风险，同样需要灰度与恢复方案。
定期做权限与规则巡检
季度巡检至少回答：哪些仓库不在组织基线范围，哪些团队有 Admin，哪些 App 或角色能 bypass，哪些 required check 已停用，哪些 CODEOWNERS 团队无人，哪些仓库长期没有 owner，哪些规则过去发生过 Bypass。
成员离职或转组时，组织与团队回收优先于逐仓库处理；随后检查个人直接授权、外部协作者、PAT、deploy key、App 安装和待处理邀请。共享管理员账号无法把操作归因到个人，应禁止。
让审计证据活得比平台窗口更久
Rule Insights 适合排查规则行为，组织 Audit Log 适合追踪组织级操作，两者不是无限期合规档案。团队根据监管和事故复盘周期确定保留时间，把所需事件定期导出到访问受控、不可随意篡改的日志系统，并限制谁能读取包含成员和仓库元数据的导出。
规则叠加导致隐形停摆
组织、仓库与旧保护规则同时存在时，维护者可能只看到自己能编辑的一层。现象是审批数、签名或检查要求“莫名增加”；判断入口是有效规则 API、仓库 /rules 页面和来源类型。治理上要给每条基线唯一名称和 owner，迁移旧规则时逐项验证，不用管理员 bypass 维持日常交付。
Bypass 把管理员账号变成单点风险
一个 always bypass 的 Admin 或 App 可以让所有其他门禁失去意义。判断标准不是“只有可信人员”，而是该身份被盗、误操作或离职后能否无第二人确认更新关键引用。优先使用仅 PR 绕过、独立应急团队、短期成员资格和事后审计；定期演练撤销 bypass，而不是只演练使用。
检查身份和名称会漂移
required check 是跨控制面的字符串与 App 身份契约。工作流重命名、CI 迁移、App 重装和路径过滤都可能让规则等待不存在的结果。团队要维护检查目录，变更时双轨运行，并为外部服务故障设计有审批、有时限的降级；否则安全门禁会成为不可恢复的仓库锁。
规则保护不了仓库外部控制面
Ruleset 可以限制 ref，却不能自动保护组织 owner、App 安装、仓库可见性、Webhook、Secret、环境或 Actions 策略。攻击者若获得 Admin，可能先改规则再改代码。需要把强认证、最小 Admin、组织审计、规则变更评审和外部告警结合起来，不能把 branch protection 当作完整安全边界。
Fork network 与 push ruleset 扩大影响面
Push ruleset 可对整个 fork network 的文件路径、扩展名或大小施加限制，bypass 也从 root repository 继承。这适合统一阻止危险文件，却可能影响大量贡献者和 fork 自动化。启用前先盘点 fork 模式、规则命中和套餐边界，在测试网络或 Evaluate 模式观察；规则回滚也要从根仓库执行。
审计窗口短于团队责任周期
事故可能在数月后才被发现，平台在线日志却有有限保留期。判断标准是组织要求的追溯周期是否长于当前官方窗口。若是，必须在窗口内定期导出，并验证导出完整性、时区、访问控制和检索能力；“以后需要时再去 GitHub 查”不是保留方案。
已区分 GitHub.com 与 Enterprise Server，套餐和仓库可见性能力按官方资料实测。测试仓库、普通 Write 成员、独立评审者和规则管理员均已准备。默认分支命中明确的 Active Ruleset，API 能返回预期有效规则和来源。
组织、仓库 Rulesets 与传统 branch protection 的叠加关系已盘点。默认分支必须经过 PR，普通成员不能直推、force push 或删除。审批、陈旧审批失效、对话解决和 CODEOWNERS 要求已分别验证。
已执行“审批后追加提交”实验，旧审批不能继续授权新差异。Required checks 的名称、App、触发范围、owner、超时与迁移方式有记录。Merge、Squash、Rebase、linear history 和 merge queue 的组合没有冲突。
Bypass 仅授予具体团队或 App，优先采用仅通过 PR 绕过，并有到期复核。普通成员与管理员分别验证；日常管理员不能靠默认特权绕过基线。Rule Insights 能找到 Pass、Fail、Bypass 演练，组织 Audit Log 能找到规则与权限变更。
审计保留需求超过平台窗口时，已建立受控导出或审计流。自动化使用专用 GitHub App 或最小权限凭证，不复用个人账号和长期 PAT。新仓、转移、归档、成员离职和 App 退役都有权限与规则复核动作。
规则变更保存前后快照、评审理由、验证证据和回滚步骤。练习 PR、分支和本地规则导出文件已清理。操作记录没有真实组织名、仓库地址、账号、代理信息、内部路径或凭证。