Heim

Skill

Codeüberprüfung

mcore-split-pr

nvidia/skills

Teilen Sie einen Pull Request in mehrere Pull Requests auf, um die Anzahl der erforderlichen CODEOWNERS-Prüfgruppen zu verringern.

...Alle erweitern

Zeit aktualisiert 26. August 2026

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

Über mcore-split-pr

Die Funktion mcore-split-pr hilft dabei, einen großen Pull Request von Megatron-LM in mehrere kleinere PRs aufzuteilen, wodurch jeweils nur so wenige CODEOWNERS-Prüfgruppen wie möglich betroffen sind. Sie löst ein konkretes Problem der hohen Prüflast: Ein PR, der Kernkomponenten, Beispiele, Tools sowie Trainingsverzeichnisse umfasst, zieht viele Prüfgruppen hinzu und verlangsamt somit die Fusionen, während ein PR, der auf ein einziges Verzeichnis beschränkt ist, nur die Prüfer dieses Verzeichnisses benötigt.

Der Arbeitsablauf umfasst drei Phasen. Zunächst analysiert die Funktion den PR, indem sie seine Details sowie die Diff-Statistiken über die gh CLI abruft, das Dateiformat .github/CODEOWNERS analysiert, um Dateimuster den zuständigen Gruppen zuzuordnen, und die Anzahl der verschiedenen Prüfgruppen ermittelt, die der PR derzeit benötigt. Anschließend schlägt sie eine Aufteilung vor, bei der Dateien nach ihren CODEOWNERS-Gruppen gruppiert werden, Tests zusammen mit dem Produktionscode, den sie überprüfen, beibehalten werden, Abhängigkeiten zwischen verschiedenen PRs markiert werden (zum Beispiel Symbole, die in einem PR umbenannt wurden und von einem anderen PR verwendet werden), gewährleistet wird, dass jeder entstehende PR unabhängig fusioniert werden kann, und der Plan in Form einer Tabelle zur Freigabe durch den Benutzer dargestellt wird. Erst nach der Freigabe führt die Funktion die Aufteilung aus, indem sie Branches vom richtigen Basisverzeichnis erstellt, dateispezifische Diffs mithilfe von git apply anwendet, Commits vornimmt und die Änderungen in das Fork des Benutzers hochlädt. Dabei werden immer PRs als Entwürfe erstellt, niemals direkt in das Hauptrepositorium hochgeladen, vor jedem Force-Push wird die Bestätigung des Benutzers eingeholt, und bei Nichtidentität des aktuellen Benutzers mit dem ursprünglichen Autor wird dieser geehrt.

Zielgruppe sind Mitwirkende und Wartungsteams von Megatron-LM, die mit umfangreichen PRs zu kämpfen haben und die Anzahl der Prüfgruppen pro PR verringern möchten, ohne dass jede Aufteilung nicht unabhängig überprüft und gefusioniert werden kann. Die Funktion kann vom Benutzer über die URL oder Nummer eines PRs aufgerufen werden.

FAQ

Welches Problem löst das Aufteilen eines PRs?

Es reduziert die Anzahl der CODEOWNERS-Prüfgruppen, die pro PR benötigt werden, und verringert somit die Prüflast. Jeder entstehende PR muss dennoch unabhängig fusioniert und überprüft werden können.

Wird der Inhalt direkt ins Hauptrepositorium hochgeladen?

Nein. Die Funktion erstellt immer PRs als Entwürfe und lädt sie in das Fork des Benutzers hoch, niemals direkt in das Hauptrepositorium. Zudem wird vor jedem Force-Push die Bestätigung des Benutzers eingeholt, falls der ursprüngliche PR dadurch eingeschränkt wird.

Wie werden Tests während der Aufteilung behandelt?

Testdateien werden zusammen mit dem Produktionscode, den sie überprüfen, übertragen. Die Funktion vermeidet ausdrücklich, Tests in einen separaten PR zu teilen, nur um die Anzahl der Prüfgruppen zu verringern.

Was passiert, wenn ein aufgeteilter PR von einem anderen abhängt?

Die Abhängigkeit wird ausdrücklich angegeben, und in dem ersten PR werden zurückkompatible Aliasse, Neuexporte oder Puffer eingefügt, damit nachfolgende PRs von ihnen abhängen können. Zudem wird die erforderliche Reihenfolge der Fusionen angegeben.

Was ist für den Betrieb erforderlich?

Die gh CLI, die für das Repositorium authentifiziert ist, ein lokales Repository mit einem Remote-Verbindungspunkt zum Hauptrepositorium sowie ein eigenes Fork des Benutzers, auf das die Branches hochgeladen werden. Vor der Ausführung der Aufteilung wird auf die Freigabe durch den Benutzer gewartet.

Alle Dateien

5 DateienSKILL.md4,4 KBAnzeigenskill.oms.sig4,5 KBAnzeigenBENCHMARK.md2,7 KBAnzeigenevals/evals.json0,0 KBAnzeigenskill-card.md2,4 KBAnzeigen

Auf GitHub ansehen

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 #").