| 名称 | mcore-split-pr |
| 描述 | 将一个PR拆分为多个PR，以减少所需的CODEOWNERS审核组数量。 |
| 开源协议 | Apache-2.0 when_to_use: 用户要求拆分PR、减少审核组，或拆分大型PR；出现’CODEOWNERS过多’、‘拆分此PR’、‘分解PR’、'减少所需审核者’等请求。 user_invocable: true argument: “PR URL 或编号” metadata: |
| 作者 | Philip Petrakian ppetrakian@nvidia.com |
按CODEOWNERS组拆分PR
将大型拉取请求拆分为多个较小的PR，使每个PR尽可能少地涉及CODEOWNERS审核组。目标是减少审核负担：只触及megatron/core/的PR只需要核心审核者，而同时也触及examples/、tools/和megatron/training/的PR会引入许多额外的组。
首要约束（答案优先约束）
对于拆分规划问题，在完整工作流程之前，先说明以下约束：
- 最小化每个PR的CODEOWNERS审核组数量，但每个生成的PR必须仍然可以独立合并和审核。
- 测试文件与它们验证的生产代码一起移动；不要为了减少审核组而将测试拆分成单独的PR。
- 如果PR B依赖于PR A中重命名的符号，请指出依赖关系，并在需要时在PR A中放置向后兼容的别名、再导出或垫片（shims）。
- 在执行之前等待用户批准。
- 执行时从正确的基线创建草稿PR，使用
git diff upstream/main..<source-branch> -- <paths> | git apply应用文件范围的差异，推送到用户的分支，绝不直接推送到上游。
工作流程
1. 分析PR
- 获取PR详情：运行
gh pr view <number> --repo NVIDIA/Megatron-LM --json title,body,headRefName,author和gh pr diff <number> --repo NVIDIA/Megatron-LM --stat。同时通过gh api user --jq .login确定当前GitHub用户。 - 解析
.github/CODEOWNERS，构建从文件路径模式到所有者组的映射。 - 对于PR中每个更改的文件，确定哪些CODEOWNERS组需要审核它。
- 按CODEOWNERS组构建汇总表，显示哪些文件引入了哪些组。
- 统计PR当前所需的不同审核组的总数。
2. 提出最小化每个PR审核组数量的拆分方案
主要优化目标：最小化每个结果PR所需的CODEOWNERS审核组数量。
策略：
- 根据CODEOWNERS组对文件进行聚类。由同一组文件共同拥有的文件自然属于同一PR。
- 确定最大的聚类 —— 这将成为第一个（通常是最大的）PR。
- 剩余的文件形成一个或多个额外的PR，每个PR理想情况下仅需要一个或两个审核组。
- 如果拆分产生依赖关系（例如，PR B使用PR A中重命名的符号），则依赖的PR必须在第一个之后合并。请明确注明这一点。
- 每个PR必须能够独立合并到main分支 —— 不能有损坏的导入，不能有缺失的符号。在第一个PR中提供向后兼容的别名和再导出桩可以使这成为可能。
以表格形式呈现建议的拆分方案：
- PR名称/描述
- 包含的文件
- 所需的CODEOWNERS组
- 对其他PR的依赖关系（如果有）
在继续之前等待用户批准。
3. 执行拆分（用户批准后）
对于每个新PR：
- 从适当的基线（
main分支或依赖PR的分支）创建新分支。 - 提取相关更改：
git diff upstream/main..<source-branch> -- <file paths> | git apply。 - 暂存文件，使用清晰的消息提交，并推送到用户的分支。
- 将PR创建为草稿（根据仓库贡献指南）。
- 如果原始PR需要缩小范围，在强制推送前与用户确认。
- 完成后报告所有PR URL。
重要指南
- 始终将PR创建为草稿，并推送到用户的分支，绝不直接推送到上游。
- 向后兼容的更改（别名、再导出、弃用垫片）应放在第一个PR中，以便后续PR可以依赖它们。
- 测试文件应与它们测试的生产代码放在一起，而不是在单独的PR中。
- 对于每个拆分PR，优先使用单个干净提交，而不是重放原始提交历史。
- 如果文件难以分类（例如，它涉及两个组），请询问用户应将其放在哪个PR中。
- 如果当前GitHub用户不是原始PR的作者，则每个新PR的描述必须明确注明原作者（例如，“Original changes by @<author> in #<number>”）。