RustFS 开源项目的 Git 与 Pull Request 工程规范从提交到合入的完整闭环【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs导读本文围绕 RustFS 仓库中的规范主文档 .agents/references/pull-requests.md 展开系统梳理该项目在提交commit、推送push、Pull Request、Issue 与 Discussion 动作上的全部硬性规则包括 PR 提交前预检清单、PR 生命周期管理、Conventional Commits 基线、验证层级Verification Tier与本地门禁命令。读者完成后将掌握一套可直接复制的提交前自检 → 开 PR → 监控 → 合入 → 清理完整工作流并理解规则背后的源码与 CI 证据适合计划向 RustFS 贡献代码的开发者以及希望借鉴其工程化规范的团队。一、规范体系一份主文档分层权威RustFS 的 Git 与 PR 规则并非散落各处而是有明确的单一权威来源single normative home主文档.agents/references/pull-requests.md 适用于 commits、pushes、PRs 以及 issue/discussion 动作文内所有路径均为仓库根目录相对路径repository-relative。根级 AGENTS.mdAGENTS.md 中的 Git and PR Baseline 一节是 Git 与 PR 基线的唯一规范出处single normative home。根据 .github/AGENTS.md 的明确说明其他文件不得重复复制这些规则以避免副本过期导致规范漂移。任务触发规则根 AGENTS.md 规定在提交、推送、创建/更新 PR、或在 PR/Issue/Discussion 上发布内容之前必须先阅读该主文档并且引用文档本身不授权任何发布、合并或发布动作——授权来自用户请求与既有授权。同时权限边界由用户授权与根AGENTS.md共同约束GitHub 仓库的作用域scope由用户请求决定。这套分层设计保证了规则可追溯、授权不越界。二、最终 PR 预检Final PR Preflight提交前的最后一道闸门在创建或更新 PR 之前必须复用已经完成的评审与验证结果逐项确认以下内容预检项具体要求核实 base 与完整 diff确认实际 base通常是origin/main检查完整任务 diff包括文件名与空白差异whitespace排除无关内容diff 中不得包含 secrets、日志、生成产物generated artifacts与无关修改unrelated edits保留已有 PR 的 base除非用户明确要求否则不得更改既有 PR 的 base验证层级通过确认最终 diff 已通过根级验证层见下文验证层级修复任务归属的失败并补跑缺失的作用域检查如实上报若存在未解决的必需检查required checks或权限缺口如实报告不得通过扩大任务范围来掩盖提交信息格式英文 Conventional Commit 标题长度不超过72 字符使用模板标题template headings、真实运行的检查、实质性风险与回滚说明写库前复核在写入 GitHub 的前一刻再次确认 head 与 task diff 未发生变化只重跑被编辑或相关状态变更所失效的检查这条预检清单的核心思想是**先复用、后补缺、写前复核**不重复启动新的一轮完整评审而是信任已完成验证仅针对新增变更做增量校验。三、Pull Request 生命周期Lifecycle管理主文档对 PR 从创建到合入后清理的全过程给出了明确节奏创建/更新的即时快照创建或更新 PR 时包含一次立即执行的检查快照checks、mergeability、reviews、unresolved threads。默认交接而非驻留除非用户明确要求监控、release 工作流需要监控、或已有自动化接管PR 打开后即应交接hand off交付当前状态与下一个要观察的事件不得用固定静默期睡眠quiet-period sleeps拖延普通交接。监控采用事件驱动或有界等待被要求监控时只上报状态变化、可操作的失败或有意义的长时间延迟不做无意义的轮询刷屏。先调查后改码遇到失败或评审意见先调查根因再修改代码修复任务归属问题 → 重跑受影响的验证 → 推送 → 回复或解决线程 → 恢复监控。合入门禁未经必需的 reviewer 批准或明确授权绝不合并Never merge without required reviewer approval or explicit authority。合入后清理观察到合入成功后先验证 commit 确实到达 base再在安全前提下清理任务工作树/分支对于被关闭的 PR除非明确授权删除否则保留未合并的工作Preserve unmerged work for closed PRs。这套生命周期规则与 .agents/skills/pr-review/SKILL.md 中的处理后续Handle follow-up步骤互相咬合复审后续提交时须先 fetch 新 head并将已评审 SHA 与新 SHA 对比绝不能用未 fetch 的origin/pull/N/headref 作为证据。四、Git 与 PR 基线BaselineCommit 与 PR 的硬性格式4.1 Conventional Commits 与 72 字符上限所有提交遵循 Conventional Commits 规范subject 不超过72 字符。仓库实际提交风格可参考根 AGENTS.md 与 CONTRIBUTING.md 中给出的示例例如fix: improve s3-tests readiness detection这类类型前缀 英文短描述格式。4.2 全英文原则源码注释、commit、PR 标题、PR 正文一律使用英文。PR 讨论过程中可以与 reviewer 用中文交流但正式产物PR 本身、标题、描述、全部正式文档必须是英文——这一点在 CONTRIBUTING.md 的 Pull Request Guidelines 一节有同样要求。4.3 模板完整性与--body-file必须保留 .github/pull_request_template.md 中的每一个标题heading用不上时以N/A填充并列出实际运行过的命令。多行内容一律使用--body-file传文件的方式创建/编辑 PR禁止把多行文本直接内联到gh pr create/gh pr edit的--body参数中。这与 PR 评审技能中Always use--body-fileor--input, never inline multiline--body的要求一致。4.4 文本与路径卫生PR/issue/discussion 内容中不得出现字面量序列\n也不得出现硬换行的散文段落hard-wrapped prose paragraphs。GitHub 内容中不得包含本地绝对路径或工具特有的标签/前缀tool-specific labels/prefixes。评审线程review threads在底层问题修复后才可标记解决若拒绝某条建议应附上简短的、基于证据的理由回复a short evidence-based reason。五、PR 模板逐节解析评审者与机器人都在读它.github/pull_request_template.md 是 RustFS 所有 PR 的格式基准共 5 个必填区块Related Issues列出关联 issue例如Fixes #123无关联时写N/A。Summary of Changes描述具体问题与结果行为若为行为变更需指明触发该行为的输入或状态与预期结果并解释新引入的依赖或抽象。Verification给出 1–3 条变更行为的具体证据——测试或命令、观察到的结果、该证据防住的回归bug 修复须记录修复前失败/修复后通过或说明为何无法提供须注明被测试的 commit 与本地改动未运行的检查与残余风险也要列出纯文档改动只需列出适用的文档检查。Impact说明用户可见、兼容性、API、部署、配置或文档影响无影响写N/A。Additional Notes供评审者参考的补充信息或N/A。模板尾部还引导首次贡献者阅读 CODE_OF_CONDUCT.md并提示阅读 CLA 文档后在 PR 上评论I have read and agree to the CLA.完成签署。仓库.github/ISSUE_TEMPLATE/下同时提供bug_report.md与feature_request.md与 PR 模板共同构成完整的贡献表单体系。六、验证层级Verification Tier按 diff 类型选择门禁根 AGENTS.md 的 Verification 一节规定了按最终任务 diff 选择检查的分层原则作用域AGENTS.md可以增加具体的路径检查但不得用通用全工作区门禁取代本分层变更类型必跑检查文档与指令类prose、注释、agent 指令、skill 元数据git diff --check 相关文档 guard/技能校验器跳过 Cargo 格式化、编译、Clippy、测试与make pre-commit/make pre-pr非行为性源码改动对应语言的格式化/校验器仅当语法或可执行示例变化时才加编译或 doctest局部行为改动Rustcargo fmt --all --check 覆盖该行为的最窄测试仅当目标、feature、公共 API、错误处理或控制流未被聚焦测试覆盖时才加包级cargo check/Clippy广泛跨模块改动默认不运行make pre-pr仅当最终 diff 很宽、跨多模块且定向检查无法界定影响面时才考虑配套约束还包括绝不为了变绿而削弱门禁——不得新增 baseline/allowance、压制 lint、忽略测试或放宽断言除非该策略变更本身就是被评审的任务。根AGENTS.md还禁止提交一次性计划、追踪表、迁移台账、基准快照等碎片由 scripts/check_no_planning_docs.sh 强制这一边界。七、本地门禁速查make pre-commit 与 make pre-prCONTRIBUTING.md 给出了本地验证的完整命令矩阵# 格式化与校验 cargo fmt --all cargo fmt --all --check cargo clippy --all-targets --all-features -- -D warnings cargo check --all-targets # 等价 Makefile 目标 make fmt make fmt-check make clippy-check make quick-check # cargo check --workspace --exclude e2e_test make compilation-check # cargo check --all-targets make pre-commit # 快速门禁见下 make pre-pr # 完整门禁 pre-commit clippy tests其中make pre-commit是快速门禁按序运行详见 CONTRIBUTING.md 对.config/make/pre-commit.mak的说明fmt-check—cargo fmt --all --checkunsafe-code-check— scripts/check_unsafe_code_allowances.sharchitecture-migration-check— scripts/check_architecture_migration_rules.shlogging-guardrails-check— scripts/check_logging_guardrails.shtokio-io-uring-check— scripts/check_no_tokio_io_uring.shextension-schema-check— scripts/check_extension_schema_boundaries.shdoc-paths-check— scripts/check_doc_paths.shquick-check—cargo check --workspace --exclude e2e_test注意make pre-commit不运行 clippy 也不运行任何测试它不能替代针对具体改动的 scoped Clippy 与测试检查。make pre-pr则是完整门禁pre-commit 的 guard 检查 clippy-check test仅建议用于跨模块的大改动。此外仓库还提供可选的 Git 预提交钩子.pre-commit-config.yaml 中定义的本地钩子rustfs-fmt-check会在暂存文件包含 Rust 源码时运行cargo fmt --all --check不编译、不跑测试通过make setup-hooks安装若使用core.hooksPath安装器会拒绝静默覆盖既有钩子管理器。八、CI 强制与工作流改动纪律根 AGENTS.md 的 Sources of Truth 明确本地门禁以Makefile与.config/make/为准CI 门禁以 .github/workflows/ci.yml 为准PR 格式以 .github/pull_request_template.md 为准。这意味着即使本地全绿最终仍以 CI 配置的仓库门禁为准。针对.github/workflows/的改动.github/AGENTS.md 额外规定任何改动必须通过actionlint从仓库根运行且零发现zero findingsmake pre-pr不覆盖工作流文件因此这是工作流改动的必需检查自定义自托管 runner 标签sm-standard-*、dind-*在 .github/actionlint.yaml 中声明引入新runs-on:标签必须同步声明禁止用配置或-ignore掩盖真实发现——必须通过修复工作流本身来让检查通过若安装了 shellcheckactionlint 还会对run:脚本做 lint这些发现同样属于门禁。仓库.github/workflows/下还提供了与 PR 流程配套的自动化佐证例如ci.yml、cla.ymlCLA 检查、coverage.yml、e2e-*.yml系列以及被手动禁用的stale.yml其文件头注释还记录了一次因仅看文件看不出 Actions 设置里被禁用而误导审计的教训说明仓库状态 ≠ UI 状态。九、PR 评审工作流工具化闭环.agents/skills/pr-review/SKILL.md 将上述 PR 规则落实为一套可执行的命令行工作流可作为贡献者自查的范本# 1. 收集 PR 上下文 gh pr view N --repo owner/repo --json title,author,state,body,additions,deletions,changedFiles,commits,baseRefName,headRefName,baseRefOid,headRefOid gh pr diff N --repo owner/repo --name-only # 2. 拉取 diff 并分类变更 git fetch repo-remote baseRefName refs/pull/N/head git diff baseRefOid...headRefOid --stat # 3. 检查 CI 状态 gh pr checks N --repo owner/repo gh run view --repo owner/repo --log-failed --jobJOB_ID # 4. 发布评审一律 --body-file gh pr review N --repo owner/repo --request-changes --body-file /tmp/pr_review.md gh pr review N --repo owner/repo --approve --body-file /tmp/pr_review.md gh pr review N --repo owner/repo --comment --body-file /tmp/pr_review.md若需行内评审意见则按 .agents/skills/pr-review/references/posting.md 构造 JSON 并通过gh api --method POST /repos/{owner}/{repo}/pulls/N/reviews --input /tmp/pr_review.json提交其中commit_id必须绑定到被评审的 head SHA。评审纪律与 PR 规则互相印证findings 需要file:line与具体失败场景没有 findings 也是完整结果不得为凑数添加风格 nit发布前须刷新 PR head若 head 已变化则先评审增量再更新结论。十、合规要点速查表维度硬性要求提交信息Conventional Commits英文subject ≤ 72 字符语言源码注释 / commit / PR 标题 / PR 正文全英文PR 模板保留全部标题用N/A填充列出真实运行的命令多行内容gh pr create/gh pr edit一律--body-file文本格式禁止字面\n、禁止硬换行散文、禁止本地绝对路径、禁止工具前缀合并前提必需 reviewer 批准或明确授权监控方式事件驱动或有界等待只上报状态变化与可操作失败合入后验证 commit 到达 base安全时清理工作树/分支关闭的 PR 保留未合并工作验证选择按 diff 类型选层文档/非行为/局部行为/跨模块不削弱门禁工作流改动过 actionlint 零发现新 runner 标签在 actionlint.yaml 声明结语RustFS 的 Git 与 PR 规范是一个规则 → 模板 → 工具 → CI四层闭环主文档 .agents/references/pull-requests.md 定义行为基线.github/pull_request_template.md 固化格式gh命令族与 .agents/skills/pr-review/SKILL.md 提供执行路径而 .github/workflows/ci.yml 与 actionlint 负责强制落地。对贡献者而言只需要记住一个核心原则提交前复用已验证结论、开 PR 后即时交接、合入前核对授权与 diff、合入后验证并清理——其余所有细节都能在这套分层文档中逐条找到依据。【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RustFS 开源项目的 Git 与 Pull Request 工程规范：从提交到合入的完整闭环
RustFS 开源项目的 Git 与 Pull Request 工程规范从提交到合入的完整闭环【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs导读本文围绕 RustFS 仓库中的规范主文档 .agents/references/pull-requests.md 展开系统梳理该项目在提交commit、推送push、Pull Request、Issue 与 Discussion 动作上的全部硬性规则包括 PR 提交前预检清单、PR 生命周期管理、Conventional Commits 基线、验证层级Verification Tier与本地门禁命令。读者完成后将掌握一套可直接复制的提交前自检 → 开 PR → 监控 → 合入 → 清理完整工作流并理解规则背后的源码与 CI 证据适合计划向 RustFS 贡献代码的开发者以及希望借鉴其工程化规范的团队。一、规范体系一份主文档分层权威RustFS 的 Git 与 PR 规则并非散落各处而是有明确的单一权威来源single normative home主文档.agents/references/pull-requests.md 适用于 commits、pushes、PRs 以及 issue/discussion 动作文内所有路径均为仓库根目录相对路径repository-relative。根级 AGENTS.mdAGENTS.md 中的 Git and PR Baseline 一节是 Git 与 PR 基线的唯一规范出处single normative home。根据 .github/AGENTS.md 的明确说明其他文件不得重复复制这些规则以避免副本过期导致规范漂移。任务触发规则根 AGENTS.md 规定在提交、推送、创建/更新 PR、或在 PR/Issue/Discussion 上发布内容之前必须先阅读该主文档并且引用文档本身不授权任何发布、合并或发布动作——授权来自用户请求与既有授权。同时权限边界由用户授权与根AGENTS.md共同约束GitHub 仓库的作用域scope由用户请求决定。这套分层设计保证了规则可追溯、授权不越界。二、最终 PR 预检Final PR Preflight提交前的最后一道闸门在创建或更新 PR 之前必须复用已经完成的评审与验证结果逐项确认以下内容预检项具体要求核实 base 与完整 diff确认实际 base通常是origin/main检查完整任务 diff包括文件名与空白差异whitespace排除无关内容diff 中不得包含 secrets、日志、生成产物generated artifacts与无关修改unrelated edits保留已有 PR 的 base除非用户明确要求否则不得更改既有 PR 的 base验证层级通过确认最终 diff 已通过根级验证层见下文验证层级修复任务归属的失败并补跑缺失的作用域检查如实上报若存在未解决的必需检查required checks或权限缺口如实报告不得通过扩大任务范围来掩盖提交信息格式英文 Conventional Commit 标题长度不超过72 字符使用模板标题template headings、真实运行的检查、实质性风险与回滚说明写库前复核在写入 GitHub 的前一刻再次确认 head 与 task diff 未发生变化只重跑被编辑或相关状态变更所失效的检查这条预检清单的核心思想是**先复用、后补缺、写前复核**不重复启动新的一轮完整评审而是信任已完成验证仅针对新增变更做增量校验。三、Pull Request 生命周期Lifecycle管理主文档对 PR 从创建到合入后清理的全过程给出了明确节奏创建/更新的即时快照创建或更新 PR 时包含一次立即执行的检查快照checks、mergeability、reviews、unresolved threads。默认交接而非驻留除非用户明确要求监控、release 工作流需要监控、或已有自动化接管PR 打开后即应交接hand off交付当前状态与下一个要观察的事件不得用固定静默期睡眠quiet-period sleeps拖延普通交接。监控采用事件驱动或有界等待被要求监控时只上报状态变化、可操作的失败或有意义的长时间延迟不做无意义的轮询刷屏。先调查后改码遇到失败或评审意见先调查根因再修改代码修复任务归属问题 → 重跑受影响的验证 → 推送 → 回复或解决线程 → 恢复监控。合入门禁未经必需的 reviewer 批准或明确授权绝不合并Never merge without required reviewer approval or explicit authority。合入后清理观察到合入成功后先验证 commit 确实到达 base再在安全前提下清理任务工作树/分支对于被关闭的 PR除非明确授权删除否则保留未合并的工作Preserve unmerged work for closed PRs。这套生命周期规则与 .agents/skills/pr-review/SKILL.md 中的处理后续Handle follow-up步骤互相咬合复审后续提交时须先 fetch 新 head并将已评审 SHA 与新 SHA 对比绝不能用未 fetch 的origin/pull/N/headref 作为证据。四、Git 与 PR 基线BaselineCommit 与 PR 的硬性格式4.1 Conventional Commits 与 72 字符上限所有提交遵循 Conventional Commits 规范subject 不超过72 字符。仓库实际提交风格可参考根 AGENTS.md 与 CONTRIBUTING.md 中给出的示例例如fix: improve s3-tests readiness detection这类类型前缀 英文短描述格式。4.2 全英文原则源码注释、commit、PR 标题、PR 正文一律使用英文。PR 讨论过程中可以与 reviewer 用中文交流但正式产物PR 本身、标题、描述、全部正式文档必须是英文——这一点在 CONTRIBUTING.md 的 Pull Request Guidelines 一节有同样要求。4.3 模板完整性与--body-file必须保留 .github/pull_request_template.md 中的每一个标题heading用不上时以N/A填充并列出实际运行过的命令。多行内容一律使用--body-file传文件的方式创建/编辑 PR禁止把多行文本直接内联到gh pr create/gh pr edit的--body参数中。这与 PR 评审技能中Always use--body-fileor--input, never inline multiline--body的要求一致。4.4 文本与路径卫生PR/issue/discussion 内容中不得出现字面量序列\n也不得出现硬换行的散文段落hard-wrapped prose paragraphs。GitHub 内容中不得包含本地绝对路径或工具特有的标签/前缀tool-specific labels/prefixes。评审线程review threads在底层问题修复后才可标记解决若拒绝某条建议应附上简短的、基于证据的理由回复a short evidence-based reason。五、PR 模板逐节解析评审者与机器人都在读它.github/pull_request_template.md 是 RustFS 所有 PR 的格式基准共 5 个必填区块Related Issues列出关联 issue例如Fixes #123无关联时写N/A。Summary of Changes描述具体问题与结果行为若为行为变更需指明触发该行为的输入或状态与预期结果并解释新引入的依赖或抽象。Verification给出 1–3 条变更行为的具体证据——测试或命令、观察到的结果、该证据防住的回归bug 修复须记录修复前失败/修复后通过或说明为何无法提供须注明被测试的 commit 与本地改动未运行的检查与残余风险也要列出纯文档改动只需列出适用的文档检查。Impact说明用户可见、兼容性、API、部署、配置或文档影响无影响写N/A。Additional Notes供评审者参考的补充信息或N/A。模板尾部还引导首次贡献者阅读 CODE_OF_CONDUCT.md并提示阅读 CLA 文档后在 PR 上评论I have read and agree to the CLA.完成签署。仓库.github/ISSUE_TEMPLATE/下同时提供bug_report.md与feature_request.md与 PR 模板共同构成完整的贡献表单体系。六、验证层级Verification Tier按 diff 类型选择门禁根 AGENTS.md 的 Verification 一节规定了按最终任务 diff 选择检查的分层原则作用域AGENTS.md可以增加具体的路径检查但不得用通用全工作区门禁取代本分层变更类型必跑检查文档与指令类prose、注释、agent 指令、skill 元数据git diff --check 相关文档 guard/技能校验器跳过 Cargo 格式化、编译、Clippy、测试与make pre-commit/make pre-pr非行为性源码改动对应语言的格式化/校验器仅当语法或可执行示例变化时才加编译或 doctest局部行为改动Rustcargo fmt --all --check 覆盖该行为的最窄测试仅当目标、feature、公共 API、错误处理或控制流未被聚焦测试覆盖时才加包级cargo check/Clippy广泛跨模块改动默认不运行make pre-pr仅当最终 diff 很宽、跨多模块且定向检查无法界定影响面时才考虑配套约束还包括绝不为了变绿而削弱门禁——不得新增 baseline/allowance、压制 lint、忽略测试或放宽断言除非该策略变更本身就是被评审的任务。根AGENTS.md还禁止提交一次性计划、追踪表、迁移台账、基准快照等碎片由 scripts/check_no_planning_docs.sh 强制这一边界。七、本地门禁速查make pre-commit 与 make pre-prCONTRIBUTING.md 给出了本地验证的完整命令矩阵# 格式化与校验 cargo fmt --all cargo fmt --all --check cargo clippy --all-targets --all-features -- -D warnings cargo check --all-targets # 等价 Makefile 目标 make fmt make fmt-check make clippy-check make quick-check # cargo check --workspace --exclude e2e_test make compilation-check # cargo check --all-targets make pre-commit # 快速门禁见下 make pre-pr # 完整门禁 pre-commit clippy tests其中make pre-commit是快速门禁按序运行详见 CONTRIBUTING.md 对.config/make/pre-commit.mak的说明fmt-check—cargo fmt --all --checkunsafe-code-check— scripts/check_unsafe_code_allowances.sharchitecture-migration-check— scripts/check_architecture_migration_rules.shlogging-guardrails-check— scripts/check_logging_guardrails.shtokio-io-uring-check— scripts/check_no_tokio_io_uring.shextension-schema-check— scripts/check_extension_schema_boundaries.shdoc-paths-check— scripts/check_doc_paths.shquick-check—cargo check --workspace --exclude e2e_test注意make pre-commit不运行 clippy 也不运行任何测试它不能替代针对具体改动的 scoped Clippy 与测试检查。make pre-pr则是完整门禁pre-commit 的 guard 检查 clippy-check test仅建议用于跨模块的大改动。此外仓库还提供可选的 Git 预提交钩子.pre-commit-config.yaml 中定义的本地钩子rustfs-fmt-check会在暂存文件包含 Rust 源码时运行cargo fmt --all --check不编译、不跑测试通过make setup-hooks安装若使用core.hooksPath安装器会拒绝静默覆盖既有钩子管理器。八、CI 强制与工作流改动纪律根 AGENTS.md 的 Sources of Truth 明确本地门禁以Makefile与.config/make/为准CI 门禁以 .github/workflows/ci.yml 为准PR 格式以 .github/pull_request_template.md 为准。这意味着即使本地全绿最终仍以 CI 配置的仓库门禁为准。针对.github/workflows/的改动.github/AGENTS.md 额外规定任何改动必须通过actionlint从仓库根运行且零发现zero findingsmake pre-pr不覆盖工作流文件因此这是工作流改动的必需检查自定义自托管 runner 标签sm-standard-*、dind-*在 .github/actionlint.yaml 中声明引入新runs-on:标签必须同步声明禁止用配置或-ignore掩盖真实发现——必须通过修复工作流本身来让检查通过若安装了 shellcheckactionlint 还会对run:脚本做 lint这些发现同样属于门禁。仓库.github/workflows/下还提供了与 PR 流程配套的自动化佐证例如ci.yml、cla.ymlCLA 检查、coverage.yml、e2e-*.yml系列以及被手动禁用的stale.yml其文件头注释还记录了一次因仅看文件看不出 Actions 设置里被禁用而误导审计的教训说明仓库状态 ≠ UI 状态。九、PR 评审工作流工具化闭环.agents/skills/pr-review/SKILL.md 将上述 PR 规则落实为一套可执行的命令行工作流可作为贡献者自查的范本# 1. 收集 PR 上下文 gh pr view N --repo owner/repo --json title,author,state,body,additions,deletions,changedFiles,commits,baseRefName,headRefName,baseRefOid,headRefOid gh pr diff N --repo owner/repo --name-only # 2. 拉取 diff 并分类变更 git fetch repo-remote baseRefName refs/pull/N/head git diff baseRefOid...headRefOid --stat # 3. 检查 CI 状态 gh pr checks N --repo owner/repo gh run view --repo owner/repo --log-failed --jobJOB_ID # 4. 发布评审一律 --body-file gh pr review N --repo owner/repo --request-changes --body-file /tmp/pr_review.md gh pr review N --repo owner/repo --approve --body-file /tmp/pr_review.md gh pr review N --repo owner/repo --comment --body-file /tmp/pr_review.md若需行内评审意见则按 .agents/skills/pr-review/references/posting.md 构造 JSON 并通过gh api --method POST /repos/{owner}/{repo}/pulls/N/reviews --input /tmp/pr_review.json提交其中commit_id必须绑定到被评审的 head SHA。评审纪律与 PR 规则互相印证findings 需要file:line与具体失败场景没有 findings 也是完整结果不得为凑数添加风格 nit发布前须刷新 PR head若 head 已变化则先评审增量再更新结论。十、合规要点速查表维度硬性要求提交信息Conventional Commits英文subject ≤ 72 字符语言源码注释 / commit / PR 标题 / PR 正文全英文PR 模板保留全部标题用N/A填充列出真实运行的命令多行内容gh pr create/gh pr edit一律--body-file文本格式禁止字面\n、禁止硬换行散文、禁止本地绝对路径、禁止工具前缀合并前提必需 reviewer 批准或明确授权监控方式事件驱动或有界等待只上报状态变化与可操作失败合入后验证 commit 到达 base安全时清理工作树/分支关闭的 PR 保留未合并工作验证选择按 diff 类型选层文档/非行为/局部行为/跨模块不削弱门禁工作流改动过 actionlint 零发现新 runner 标签在 actionlint.yaml 声明结语RustFS 的 Git 与 PR 规范是一个规则 → 模板 → 工具 → CI四层闭环主文档 .agents/references/pull-requests.md 定义行为基线.github/pull_request_template.md 固化格式gh命令族与 .agents/skills/pr-review/SKILL.md 提供执行路径而 .github/workflows/ci.yml 与 actionlint 负责强制落地。对贡献者而言只需要记住一个核心原则提交前复用已验证结论、开 PR 后即时交接、合入前核对授权与 diff、合入后验证并清理——其余所有细节都能在这套分层文档中逐条找到依据。【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考