Hogar

Skill

Revisión de código

mcore-split-pr

nvidia/skills

Divida una PR en varias PR para reducir la cantidad de grupos de revisores CODEOWNERS necesarios.

...Expandir todo

Tiempo actualizado 26 de agosto de 2026

# automation # github # code-review # git # pull-request # Code ReviewGit & Version ControlProductivity & Workflow

Acerca de mcore-split-pr

La habilidad mcore-split-pr ayuda a dividir una gran solicitud de pull request de Megatron-LM en varias solicitudes más pequeñas, de modo que cada una afecte al menor número posible de grupos de revisores CODEOWNERS. Resuelve un problema concreto relacionado con la carga de revisión: una solicitud que abarca directorios de código principal, ejemplos, herramientas y entrenamiento involucra a muchos grupos de revisores, lo que ralentiza las fusiones, mientras que una solicitud limitada a un único directorio solo necesita a los revisores de ese directorio.

El flujo de trabajo consta de tres fases. Primero, analiza la solicitud de pull request obteniendo sus detalles y estadísticas de diferencias mediante gh CLI, parseando el archivo .github/CODEOWNERS para asociar patrones de archivos a grupos de propietarios, y contando los grupos de revisores distintos que la solicitud requiere actualmente. Luego, propone una división que agrupa los archivos según sus grupos CODEOWNERS, mantiene las pruebas junto al código de producción que validan, marca las dependencias entre solicitudes (por ejemplo, símbolos renombrados en una solicitud de la que depende otra), se asegura de que cada solicitud resultante sea viable para su fusión de forma independiente, y presenta el plan en forma de tabla para su aprobación por parte del usuario. Finalmente, y solo tras la aprobación, ejecuta la división creando ramas a partir de la base adecuada, aplicando diferencias específicas para cada archivo con git apply, realizando commits y subiendo los cambios al fork del usuario. Siempre crea las solicitudes de pull request como borradores, nunca las sube directamente al repositorio principal, confirma antes de realizar cualquier push forzado que reduzca la solicitud original, y atribuye el crédito al autor original cuando el usuario actual no es quien creó la solicitud.

Los usuarios destinatarios son los colaboradores y mantenedores de Megatron-LM que trabajan con solicitudes de pull request muy extensas y desean reducir el número de grupos de revisores por solicitud, manteniendo al mismo tiempo la posibilidad de revisar y fusionar cada parte de forma independiente. Puede ser invocado por el usuario mediante la URL o número de una solicitud de pull request como argumento.

Preguntas frecuentes

¿Qué problema resuelve la división de una solicitud de pull request?

Minimiza el número de grupos de revisores CODEOWNERS necesarios por solicitud, reduciendo así la carga de revisión. Cada solicitud de pull request resultante debe seguir siendo viable para su fusión y revisión de forma independiente.

¿Sube los cambios directamente al repositorio principal?

No. Siempre crea las solicitudes de pull request como borradores y las sube al fork del usuario, nunca directamente al repositorio principal. Además, consulta al usuario antes de realizar cualquier push forzado que reduzca la solicitud original.

¿Cómo se manejan las pruebas durante la división?

Los archivos de pruebas se envían junto al código de producción que validan. Esta habilidad evita explícitamente dividir las pruebas en una solicitud de pull request separada solo con el fin de reducir el número de grupos de revisores.

¿Qué ocurre cuando una solicitud de pull request resultante depende de otra?

Indica explícitamente dicha dependencia y coloca alias compatibles con versiones anteriores, reexportaciones o complementos en la primera solicitud de pull request para que las solicitudes posteriores puedan depender de ellas, además de indicar el orden de fusión necesario.

¿Qué se necesita para que funcione?

La CLI gh autenticada para el repositorio, un checkout local con un remoto upstream, y un fork del usuario al que subir las ramas. Espera la aprobación del usuario antes de ejecutar la división.

Todos los archivos

5 archivosSKILL.md4.4 KBVerskill.oms.sig4.5 KBVerBENCHMARK.md2.7 KBVerevals/evals.json0.0 KBVerskill-card.md2.4 KBVer

Ver en GitHub

Split a large pull request into multiple smaller PRs, where each PR touchesthe fewest possible CODEOWNERS reviewer groups. The goal is to reduce reviewburden: a PR that only touches megatron/core/ needs only the core reviewers,while a PR that also touches examples/, tools/, and megatron/training/pulls in many additional groups.

Answer-First Constraints

For split-planning questions, lead with these constraints before the fullworkflow:

Minimize CODEOWNERS reviewer groups per PR, but each resulting PR must stillbe independently mergeable and reviewable.
Tests travel with the production code they validate; do not split tests into aseparate PR just to reduce reviewer groups.
If PR B depends on symbols renamed in PR A, call out the dependency and putbackward-compatible aliases, re-exports, or shims in PR A when needed.
Wait for user approval before execution.
Execution creates draft PRs from the right base, applies file-scoped diffswith git diff upstream/main..<source-branch> -- <paths> | git apply, pushesto the user's fork, and never pushes directly to upstream.

Workflow

1. Analyze the PR

Fetch the PR details: gh pr view <number> --repo NVIDIA/Megatron-LM --json title,body,headRefName,author and gh pr diff <number> --repo NVIDIA/Megatron-LM --stat. Also determine the current GitHub user with gh api user --jq .login.
Parse .github/CODEOWNERS to build a mapping from file path patterns to owner groups.
For each changed file in the PR, determine which CODEOWNERS groups would be required to review it.
Build a summary table grouped by CODEOWNERS group, showing which files pull in which groups.
Count the total number of distinct reviewer groups the PR currently requires.

2. Propose a split that minimizes reviewer groups per PR

The primary optimization goal: minimize the number of CODEOWNERS reviewer groups required for each resulting PR.

Strategy:

Cluster files by their CODEOWNERS groups. Files owned by the same set of groups naturally belong together.
Identify the largest cluster — this becomes the first (and usually largest) PR.
Remaining files form one or more additional PRs, each ideally requiring only one or two reviewer groups.
If a split creates a dependency (e.g., PR B uses symbols renamed in PR A), the dependent PR must be merged after the first. Note this explicitly.
Each PR must be independently mergeable to main — no broken imports, no missing symbols. Backward-compatible aliases and re-export stubs in the first PR can make this possible.

Present the proposed split as a table:

PR name/description
Files included
CODEOWNERS groups required
Dependencies on other PRs (if any)

Wait for user approval before proceeding.

3. Execute the split (after user approval)

For each new PR:

Create a new branch from the appropriate base (main, or a dependency PR's branch).
Extract the relevant changes: git diff upstream/main..<source-branch> -- <file paths> | git apply.
Stage, commit with a clear message, and push to the user's fork.
Create the PR as a draft (per repo contributing guidelines).
If the original PR needs to be narrowed in scope, confirm with the user before force-pushing.
Report all PR URLs when done.

Important guidelines

Always create PRs as drafts and push to the user's fork, never directly to upstream.
Backward-compatible changes (aliases, re-exports, deprecation shims) should go in the first PR so subsequent PRs can depend on them.
Test files should go with the production code they test, not in a separate PR.
Prefer a single clean commit per split PR over replaying the original commit history.
If a file is hard to categorize (e.g., it touches two groups), ask the user which PR it should go in.
If the current GitHub user is not the author of the original PR, each new PR's description must explicitly credit the original author (e.g., "Original changes by @ in #").