プルリクエストの管理

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

プルリクエストは、主に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」とラベル付けされた問題を探してください。
  • mainでの失敗に関連していると思われる問題が見つかった場合は、プルリクエストに戻り、これらの変更を提案してくれた著者に感謝し、テストの失敗が彼らの特定の変更とは関係ない可能性があることを知らせてください（CI Test Failureの問題へのリンクを忘れずに含めてください。これにより、著者はいつテストを再実行できるかを知るのに役立ちます）。
  • mainで観察された問題を説明する既存のCI Test Failureの問題が見つからない場合は、新しい問題を提出し、「CI Test Failure」ラベルを使用して、mainが壊れていることを他の人に知らせてください（例については、この問題を参照）。

PRの優先順位付けの方法

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

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

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

インポートされると、変更は一連のテストを受けます。これらのテストの中には、ランドブロックテスト（land-blocking tests）と呼ばれるものがあり、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はインポートされましたが、変更はまだ適用されていません。