プルリクエストの管理

プルリクエストのレビューにはかなりの時間がかかることがあります。場合によっては、誰かが変更を記述して提出するよりも、レビューに多くの時間を要することがあります。したがって、各プルリクエストがレビューに適した状態であることを確認するために、いくつかの準備作業を行う必要があります。

プルリクエストは3つの主要なセクションで構成されるべきです。

• 概要。これは、変更の動機を理解するのに役立ちます。
• 変更履歴。これは、リリースノートの作成に役立ちます。また、変更点の簡単な要約としても機能します。
• テスト計画。これは、プルリクエストの最も重要な部分かもしれません。テスト計画は、レビュー担当者が変更が意図どおりに機能していることを確認できるように、再現可能なステップバイステップのガイドである必要があります。ユーザーに見える変更については、スクリーンショットやビデオを添付することもお勧めします。

どんなプルリクエストでも、React Native の特定の領域について、あなたが慣れていない可能性のある深い理解を必要とすることがあります。プルリクエストをレビューするのに適任ではないと感じる場合でも、ラベルを追加したり、作者にさらなる情報を求めたりすることで、まだ役立つことができます。

PRのレビュー

プルリクエストは、マージされる前にGitHubのレビュー機能を使用してレビューおよび承認される必要があります。誰でもプルリクエストをレビューおよび承認できますが、承認がコントリビューターのいずれかから得られた場合にのみ、プルリクエストがマージ準備完了であると見なされます。

レビューする自信のあるプルリクエストを見つけたら、GitHubのレビュー機能を活用し、提案する変更を明確かつ丁寧に伝えてください。

変更履歴やテスト計画が不足しているとフラグ付けされたプルリクエストから始めることを検討してください。

• 変更履歴が不足していると思われるPR - PRを編集して変更履歴を自分で追加できるか確認してください。その後、「Missing Changelog」ラベルを削除します。
• テスト計画が不足しているPR - プルリクエストを開き、テスト計画を探します。テスト計画が十分であると思われる場合は、「Missing Test Plan」ラベルを削除します。テスト計画がない場合、または不完全な場合は、テスト計画の追加を検討するように作者に丁寧にコメントを追加してください。

プルリクエストは、マージされる前にすべてのテストに合格する必要があります。これらはmainのすべてのコミットとプルリクエストで実行されます。プルリクエストをレビュー準備完了にするのに役立つ迅速な方法は、プレコミットテストに失敗しているプルリクエストを検索し、修正が必要かどうかを判断することです。失敗したテストは、通常、スレッドの下部にある「Some checks were not successful.」の下に表示されます。

• main の最新のテスト実行を簡単に見てみましょう。mainはグリーンですか？もしそうなら、
  • その失敗は、このプルリクエストの変更に関連していると思われますか？作者に調査を依頼してください。
  • たとえmainが現在グリーンであったとしても、プルリクエストのコミットが、mainが破損していた時点のコミットに基づいている可能性を考慮してください。もしその可能性があると思われる場合は、作者にmainの上に自身の変更をリベースするように依頼し、プルリクエストの作業を開始した後に着地した可能性のある修正を取り込むようにしてください。
• mainが壊れているように見える場合は、「CI Test Failure」とラベル付けされたIssueを探してください。
  • mainでの失敗に関連していると思われる問題が見つかった場合は、プルリクエストに戻り、これらの変更を提案してくれた作者に感謝し、テストの失敗が彼らの特定の変更とは関係ない可能性があることを知らせてください（CI Test Failureの問題へのリンクを忘れないでください。これは作者がいつテストを再度実行できるかを知るのに役立ちます）。
  • mainで観察された問題を説明する既存のCIテスト失敗の課題が見つからない場合は、新しい課題を提出し、「CIテスト失敗」ラベルを使用して、mainが破損していることを他の人に知らせてください（例については、この課題を参照してください）。

PRの優先順位付け方法

MetaのReact Nativeチームのメンバーは、プルリクエストを迅速にレビューすることを目指しており、ほとんどのPRは1週間以内に回答が得られます。

PRはどのようにマージされますか？

React NativeのGitHubリポジトリは、実際にはMetaのモノリポジトリのサブディレクトリのミラーです。そのため、プルリクエストは従来の意味でマージされません。代わりに、「diff」としてMetaの内部コードレビューシステムにインポートする必要があります。

インポートされると、変更は一連のテストにかけられます。これらのテストの一部はランドブロッキングであり、diffの内容がマージされる前に成功する必要があります。Metaは常にmainからReact Nativeを実行しており、一部の変更では、Facebookの従業員がマージされる前に内部の変更をプルリクエストに添付する必要がある場合があります。例えば、モジュール名を変更する場合、すべてのFacebookの内部呼び出しサイトは、マージするために同じ変更で更新される必要があります。diffが正常に着地すると、変更は最終的にShipItによって単一のコミットとしてGitHubに同期されます。

Metaの従業員は、プルリクエストを2つの方法でインポートできるカスタムのGitHubブラウザ拡張機能を使用しています。プルリクエストは「fbsourceにランディング」できます。これは、インポートされ、結果のdiffが自動的に承認され、失敗がなければ、変更は最終的にmainに同期されることを意味します。また、プルリクエストは「Phabricatorにインポート」することもできます。これは、変更が内部diffにコピーされ、着地する前にさらなるレビューと承認が必要になることを意味します。

カスタムブラウザ拡張機能のスクリーンショット。「Import to fbsource」ボタンは、プルリクエストを内部にインポートするために使用されます。

ボット

プルリクエストをレビューしたり作業したりする際に、GitHubボットアカウントが残したコメントに遭遇するかもしれません。これらのボットは、プルリクエストのレビュープロセスを支援するために設定されています。詳細については、ボットリファレンスを参照してください。

プルリクエストのラベル

• Merged: クローズされたPRに適用され、その変更がコアリポジトリに組み込まれたことを示します。GitHubでプルリクエストが直接マージされないため、このラベルは必要です。代わりに、PRの変更を含むパッチがインポートされ、コードレビューのためにキューに入れられます。承認されると、Metaの内部モノリポジトリにそれらの変更を適用した結果が、新しいコミットとしてGitHubに同期されます。GitHubは、そのコミットを元のPRに帰属させないため、PRの実際の状態を伝えるラベルが必要となります。
• Blocked on FB: PRはインポートされましたが、変更はまだ適用されていません。