mcpField
M
mcore-split-pr

mcore-split-pr

github.com/nvidia開発3.8k1.8k 回インストール今日更新
リポジトリ

mcore-split-pr について

mcore-split-prは、大きなプルリクエストを独立してレビューできる小さな変更に分割するためのワークフローガイドです。CODEOWNERSのレビューチームでファイルを分類し、コードとテストの依存関係を保ち、実行前に承認を求めます。

主な機能

  1. 01変更ファイルをCODEOWNERSグループに対応付け
  2. 02レビューチームを考慮した分割案の作成
  3. 03分割PR間の依存関係の把握
  4. 04テストを対象の製品コードと一緒に管理
  5. 05ユーザーのforkにドラフトPRを作成

活用シーン

  1. 01大規模PRのレビューチーム数を削減
  2. 02独立してマージできるPR分割を計画
  3. 03承認後にforkからドラフトPRを作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/nvidia/skills --skill mcore-split-pr

インストール後、Claude Code で/mcore-split-prを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

BENCHMARK.md
skill-card.md
skill.oms.sig
evals/
evals.json

詳細

CODEOWNERS グループ別に PR を分割する

大きなプルリクエストを、各 PR が可能な限り少ない CODEOWNERS レビューグループのみを対象とするよう、複数の小さな PR に分割します。目的はレビューの負担を軽減することです。megatron/core/ のみを変更する PR なら、必要なのはコアのレビュアーだけですが、examples/、tools/、megatron/training/ も変更すると、多くの追加グループが関わることになります。

最初に提示する制約

分割計画に関する質問では、ワークフロー全体を示す前に、次の制約を提示してください。

  • PR ごとに CODEOWNERS レビューグループを最小限にします。ただし、分割後の各 PR は、それぞれ単独でマージおよびレビューできる必要があります。
  • テストは検証対象の本番コードと一緒に移動します。レビューグループを減らす目的だけで、テストを別の PR に分割しないでください。
  • PR B が PR A で名前を変更したシンボルに依存する場合は、その依存関係を明示してください。必要に応じて、後方互換性のあるエイリアス、再エクスポート、または shim を PR A に含めます。
  • 実行前にユーザーの承認を待ちます。
  • 実行時は、適切なベースからドラフト PR を作成し、git diff upstream/main..<source-branch> -- <paths> | git apply を使ってファイルを限定した差分を適用し、ユーザーのフォークにプッシュします。upstream に直接プッシュすることはありません。

ワークフロー

1. PR を分析する
  1. 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 ユーザーを確認します。
  2. .github/CODEOWNERS を解析し、ファイルパスのパターンとオーナーグループの対応表を作成します。
  3. PR 内で変更された各ファイルについて、レビューに必要となる CODEOWNERS グループを特定します。
  4. CODEOWNERS グループごとにまとめたサマリーテーブルを作成し、どのファイルがどのグループを関与させるかを示します。
  5. 現在の PR で必要な、重複のないレビュアーグループの総数を数えます。
2. PR ごとのレビューグループを最小限にする分割案を提示する

最優先の最適化目標は、分割後の各 PR に必要な CODEOWNERS レビューグループの数を最小限にすることです。

方針：

  1. ファイルを CODEOWNERS グループ別にまとめます。同じグループの組み合わせがオーナーとなっているファイルは、自然に同じ PR にまとめられます。
  2. 最大のまとまりを特定します。これは最初の（通常は最も大きな）PR になります。
  3. 残りのファイルを 1 つ以上の追加 PR に分けます。各 PR で必要となるレビューグループは、できれば 1 つか 2 つにします。
  4. 分割によって依存関係が生じる場合（例：PR B が PR A で名前を変更したシンボルを使用する場合）、依存する PR は先行する PR のマージ後にマージする必要があります。この点を明示してください。
  5. 各 PR は、main に単独でマージできる必要があります。インポートの破損やシンボルの欠落があってはなりません。最初の PR に後方互換性のあるエイリアスや再エクスポート用のスタブを追加すると、これを実現できる場合があります。

次の項目を含む表で、分割案を提示してください：

  • PR 名／説明
  • 含まれるファイル
  • 必要な CODEOWNERS グループ
  • 他の PR への依存関係（ある場合）

続行する前に、ユーザーの承認を待ちます。

3. 分割を実行する（ユーザーの承認後）

新しい PR ごとに、次の手順を実行します。

  1. 適切なベース（main または依存先 PR のブランチ）から新しいブランチを作成します。
  2. 関連する変更を抽出します：git diff upstream/main..<source-branch> -- <file paths> | git apply。
  3. ステージングし、わかりやすいメッセージでコミットして、ユーザーのフォークにプッシュします。
  4. リポジトリのコントリビューションガイドラインに従い、PR をドラフトとして作成します。
  5. 元の PR の範囲を絞る必要がある場合は、強制プッシュする前にユーザーに確認します。
  6. 完了したら、すべての PR の URL を報告します。

重要なガイドライン

  • PR は必ずドラフトとして作成し、アップストリームには直接プッシュせず、ユーザーのフォークにプッシュしてください。
  • 後方互換性のある変更（エイリアス、再エクスポート、非推奨化用のシム）は、後続の PR で依存できるよう、最初の PR に含めてください。
  • テストファイルは別の PR に分けず、テスト対象の本番コードと一緒に含めてください。
  • 元のコミット履歴を再現するより、分割した PR ごとに整理された単一のコミットを作成してください。
  • 分類しにくいファイル（たとえば、2 つのグループにまたがる変更がある場合）は、どの PR に含めるかユーザーに確認してください。
  • 現在の GitHub ユーザーが元の PR の作成者ではない場合、新しい PR の説明には、元の作成者を明記してください（例：「# での変更の原作者：@」）。

コメント

Markdown 対応