プル要求 — MRTK2

  • [アーティクル]

前提条件

以前に Microsoft プロジェクトにおいて共同作成していない場合は、共同作成のライセンス契約への署名を求められることがあります。 その場合は、PR のコメントによって通知されます。

重要

Microsoft の従業員であり、GitHub の Microsoft 組織のメンバーでない場合は、pull request を開始する前に Microsoft でのオープン ソースに関するページにアクセスして、Microsoft と GitHub のアカウントを Corpnet でリンクしてください。 事前に処理しておく必要のある事項がいくつかあります。

pull request の作成

pull request を送信する準備ができたら、main ブランチを対象に、pull request を作成します。 リリース安定化期間中のバグ修正は、最新の prerelease/* ブランチから探します。 新しい機能は常に main に入れる必要があります。

ガイドラインを読み、pull request がガイドラインを満たしていることを確認してください。

  • PR に関連する問題、機能要求、またはタスクを必ず参照します。
  • pull request に、その PR に関連するファイルや変更のみが含まれていることを確認します。
  • ドキュメントが最新であり、含まれていることを確認します。 すべてのパブリック フィールドにコメントがあることを確認します。
  • 新しい機能を追加する場合は、その機能を検証するためのテストが含まれていることを確認します (Unity テストに関するページを参照)。
  • バグを修正する場合は、バグ修正を検証するためのテストを作成します。

プロジェクトの管理者が変更をレビューします。 3 営業日以内にすべての変更を確認することを目指しています。 レビュー コメントに対応してから、トピックのブランチにプッシュし、新たにレビュー対象の内容があることを知らせるためのコメントを投稿してください。

Note

プロジェクトに送信されたすべての PR は、MRTK コードの標準ガイドに従って検査されるため、PR を送信する前にこれらを参照し、スムーズに処理されるようにしてください。

pull request のガイドライン

これらのガイドラインは、Google のエンジニアリング プラクティスに基づいています。

pull request は簡潔にする

簡潔な PR は迅速かつ十分にレビューされ、バグが発生する可能性が低く、ロールバックが容易であり、マージが容易です。

pull request は、エンジニアが 30 分以内にレビューできる程度に簡潔にする必要があります。 1 つの問題のみに対処する最小限の変更を行うようにしてください。 大規模な PR を作成する必要がある場合は、ローカル ブランチまたは MRTK の機能ブランチに入れるいくつかの PR に分割します。 新しいアセット (fbx、obj ファイルなど) を追加することは避け、既存のアセットを再利用するようにしてください。

緊急時を除き、テストは修正または機能と同じ PR に追加すること

テストは、変更によって既存のコードが無効にならないことを確認するための最適の方法ですが、pull request の送信時にテストについて忘れがちです。 テストの作成を確実にするための最善の方法は、PR と共に提出することを必須にすることです。

すべての機能およびバグ修正には、テストを関連付ける必要があります。 テストを作成するための専門知識や時間がない場合は、テストを作成するためのイシューを作成し、Consider for Current Iteration というラベルを付けてマークします。

ドキュメントは修正または機能と同じ pull request に追加すること

ほとんどの開発者は、機能の使用方法を理解するために、コードではなく、まずドキュメントを参照します。 ドキュメントを最新に保つことにより、MRTK の利用が大幅に容易になります。 ドキュメントは常に、関連する pull と一緒にバンドルして、項目が最新かつ一貫した状態に保たれるようにする必要があります。

docfx サイトでフィールドやメソッドの説明を生成できるように、すべてのパブリック フィールド、メソッド、プロパティにトリプル スラッシュの概要コメントを付けてください。 必要に応じて、Documentation フォルダー内のマークダウン ファイルを更新します。

pull request の説明で変更について明確かつ十分に説明すること

pull request の説明を明確かつ十分にすることで、レビュー担当者がレビュー対象の内容を確実に理解できるようにします。

UX を含む機能を追加する場合は、変更する機能の画像または gif を追加します。 こちらに良い例があります。 もう 1 つの提案は、こちらの pull request のように、前と後の gif を含めることです。 スクリーン キャプチャから gif を生成するためのツールとして、ScreenToGif をお勧めします。