プルリクエストの管理
プルリクエストのレビューにはかなりの時間を要することがあります。場合によっては、変更の記述と提出に要した時間よりも、レビューに時間がかかることもあります！そのため、各プルリクエストがレビュー可能な良好な状態にあるように、予備作業を行う必要があります。
プルリクエストは、主に3つのセクションで構成する必要があります。
- 概要。これにより、変更の背後にある動機を理解できます。
- 変更ログ。これにより、リリースノートを作成できます。また、変更の簡単な概要としても機能します。
- テストプラン。これは、プルリクエストの最も重要な部分かもしれません。テストプランは、レビューアーが変更が意図したとおりに機能することを検証できる、再現可能なステップバイステップガイドである必要があります。ユーザーに見える変更については、スクリーンショットやビデオを添付するのも良いアイデアです。
プルリクエストによっては、あなたが詳しくないReact Nativeの領域に関する深い理解が必要になる場合があります。自分がプルリクエストをレビューするのに適した人物ではないと感じたとしても、ラベルを追加したり、作成者に詳細情報を求めることで、依然として支援できます。
PRのレビュー
プルリクエストは、マージされる前に、GitHubのレビュー機能を使用してレビューおよび承認する必要があります。誰でもプルリクエストをレビューおよび承認できますが、通常、承認がコントリビューターの1人からのものである場合にのみ、プルリクエストをマージ準備完了と見なします。
レビューできると確信できるプルリクエストを見つけたとします。GitHubのレビュー機能を使用し、提案された変更を明確かつ丁寧に伝えてください。
変更ログまたはテストプランがないとフラグが付けられているプルリクエストから始めることを検討してください。
- 変更ログがないと思われるPR - 確認し、PRを編集して自分で変更ログを追加できるかどうかを確認してください。「変更ログがありません」ラベルを削除してください。
- テストプランがないPR - プルリクエストを開き、テストプランを探してください。テストプランが十分なようであれば、「テストプランがありません」ラベルを削除してください。テストプランがない場合、または不完全な場合は、コメントを追加して、作成者にテストプランの追加を丁寧に依頼してください。
プルリクエストは、マージされる前にすべてのテストに合格する必要があります。これらは、`main`とプルリクエストのすべてのコミットで実行されます。プルリクエストをレビュー準備完了にするための簡単な方法は、コミット前テストに失敗しているプルリクエストを検索し、修正が必要かどうかを判断することです。失敗したテストは通常、スレッドの一番下、「一部のチェックが失敗しました」の下に表示されます。
- mainの最新のテスト実行を簡単に見てください。`main`はグリーンですか？そうであれば、
- このプルリクエストの変更に関連する失敗のように見えますか？作成者に調査を依頼してください。
- `main`が現在グリーンであっても、プルリクエストのコミットが、`main`が壊れていた時点のコミットに基づいている可能性を考慮してください。この可能性があると判断した場合は、作成者にプルリクエストの作業を開始した後に発生した修正を取り込むために、`main`の上に変更をrebaseするように依頼してください。
- `main`が壊れていると思われる場合は、「CIテスト失敗」というラベルが付いた問題を探してください。
- `main`で観察された失敗に関連すると思われる問題が見つかった場合は、プルリクエストに戻り、作成者にこれらの変更を提案してくれたことに感謝し、テストの失敗は特定の変更とは無関係である可能性があると伝えます（CIテスト失敗の問題へのリンクを忘れないでください。これにより、作成者はテストを再実行できる時期を知ることができます）。
- `main`で観察された問題を説明する既存のCIテスト失敗の問題が見つからない場合は、新しい問題を提出して「CIテスト失敗」ラベルを使用し、`main`が壊れていることを他の人に知らせます（例としてこの問題を参照してください）。
PRの優先順位付け方法
MetaのReact Nativeチームのメンバーは、プルリクエストを迅速にレビューすることを目指しており、ほとんどのPRは1週間以内に回答を得られます。
PRはどのようにマージされますか？
React NativeのGitHubリポジトリは、実際にはMetaのモノレポの1つのサブディレクトリをミラーリングしたものです。そのため、プルリクエストは従来の意味ではマージされません。代わりに、Metaの内部コードレビューシステムに"diff"としてインポートする必要があります。
インポートされると、変更は一連のテストを通過します。これらのテストの中には、ランディングブロッキングテストがあり、diffの内容をマージする前に成功する必要があります。Metaは常に`main`からReact Nativeを実行しており、変更によっては、マージする前にFacebookの従業員が内部の変更をプルリクエストに添付する必要がある場合があります。たとえば、モジュール名を変更する場合、マージするには、すべてのFacebook内部呼び出し元を同じ変更で更新する必要があります。diffが正常にランディングすると、変更は最終的にShipItによって単一のコミットとしてGitHubに同期されます。
Metaの従業員は、プルリクエストを2つの方法のいずれかでインポートできるGitHub用のカスタムブラウザ拡張機能を使用しています。プルリクエストを「fbsourceにランディング」することができます。つまり、インポートされ、結果のdiffが自動的に承認され、障害がない限り、変更は最終的に`main`に同期されます。プルリクエストを「Phabricatorにインポート」することもできます。つまり、変更は、ランディングする前にさらにレビューと承認が必要な内部diffにコピーされます。
ボット
プルリクエストのレビューと作業中に、少数のGitHubボットアカウントによって残されたコメントが表示される場合があります。これらのボットは、プルリクエストのレビュープロセスを支援するために設定されています。詳細については、ボットリファレンスを参照してください。
プルリクエストラベル
マージ済み：変更がコアリポジトリに組み込まれたことを示すために、クローズ済みのPRに適用されます。プルリクエストはGitHubで直接マージされないため、このラベルが必要です。代わりに、PRの変更を含むパッチがインポートされ、コードレビューのためにキューに入れられます。承認されると、Metaの内部モノレポへのそれらの変更の適用結果が、新しいコミットとしてGitHubに同期されます。GitHubはそのコミットを元のPRに関連付けることがないため、PRの実際のステータスを伝えるラベルが必要になります。FBでブロック済み：PRはインポートされましたが、変更はまだ適用されていません。