pull request をレビューして送信する

完了

pull request (PR) とは、Learn プラットフォームに自分の知識を提供するためのチケットです。 PR を作成しましたが、宛先リポジトリの PR キューにはまだ送信していません。 多くのオープンソース プロジェクトと同様に、発行前に変更を検証するために行われる一連の検査とレビューがあります。

PR の構造

PR には、PR を作成した GitHub ユーザー、宛先リポジトリ、PR が作成されたブランチが示されます。 PR の上部には、次のようないくつかのタブがあります。

• [Conversation] タブ:他のコラボレーターからのコメントの表示と返信、ビルドとレビュー プロセス全体の通知の一覧表示、コメントの自動化を使用したアクションの実行を行うことができるダッシュボード。
• [Commits] タブ:そのブランチで行われた変更の記録。
• [Files changed] タブ:PR で変更されるファイルとその以前の状態の比較。

[Conversation] タブに注目してください。これは、更新や通知が表示され、投稿者、レビュー担当者、およびその他のコラボレーター間のディスカッションが行われる場所です。 ここにハッシュタグ コメントを追加して、アクション (PR に検証とマージの準備ができていることを示すサインオフ、プロセスを一時停止する必要がある場合の保留など) を実行することもできます。

多くの場合、PR には、ステータスを示すラベル (レビューの準備ができていないドラフト PR を指定する draft、新しいかレビューしていない PR を表す do-not-merge など) が添付されています。

検証

PR を宛先ブランチにマージする前に、1 つ以上の PR 検証プロセスを通過することが必要な場合があります。 [Pull request の作成] を選択すると、GitHub がリポジトリ用に構成された検証を実行します。 検証プロセスが完了すると、結果が PR に表示されます。

検証プロセスは、提案された変更の範囲、および宛先リポジトリのルールによって異なります。 PR を送信すると、次のうち 1 つ以上が発生することが予想されます。

• マージ可能性:ブランチ内の提案された変更が宛先ブランチと競合するかどうかを検証する、ベースライン GitHub マージ可能性テストがまず実行されます。 PR がこのテストの不合格を示した場合、処理を続行する前に、マージ競合の原因になっているコンテンツを調整する必要があります。
• Contribution Licensing Agreement (CLA):パブリック リポジトリに投稿していて、Microsoft の従業員ではない場合、提案された変更の規模によっては、初回にそのリポジトリに PR を送信するときに、短い CLA を履行するように求められる場合があります。 CLA 手順がクリアされると、PR が処理されます。
• ラベル付け:ラベルは PR に自動的に適用され、検証ワークフローの通過に応じてその状態を示します。 たとえば、新しい PR は、PR が検証、レビュー、サインオフの手順をまだ完了していないことを示す do-not-merge ラベルを自動的に受け取る場合があります。
• 検証とビルド: 自動化されたチェックにより、変更内容が検証テストに合格するかどうかが確認されます。 検証テストは、PR をマージする前にその中の 1 つ以上のファイルを変更することを求める警告またはエラーを出力する場合があります。 検証テストの結果は、レビューのために PR にコメントとして追加され、メールでも送信される場合があります。
• ステージング: 変更提案の影響を受ける記事ページは、検証合格後にレビューするために、自動的にステージング環境にデプロイされます。 PR コメントにプレビュー URL が表示されます。
• 自動マージ:PR は、検証テストと特定の基準に合格した場合、自動的にマージされることがあります。 この場合、ほかに何も実行する必要はありません。

レビューとサインオフ

もう少しです。 すべての PR 処理が完了したら、マージするためにサインオフする前に、結果 (PR コメント、プレビュー URL など) をレビューして、追加の変更が必要かどうかを判断することをお勧めします。 PR をレビューした場合、PR レビュー担当者もコメント経由でフィードバックを提供できます (マージを妨げる未解決の問題や質問がある場合)。

コメントの自動化を使用して、PR で重要なアクションを実行します。 コメントの自動化を使用すると、ユーザーは、PR に適切なラベルを割り当てて、その状態の更新や、分類を実行できます。 コメントの自動化が実装されているリポジトリで作業している場合、ハッシュタグ コメントを使用して、ラベルの割り当てまたは変更、PR のクローズ、またはマージの一時停止を行います。 たとえば、変更が完了したら、コメント「#sign-off」を入力して、PR ラベルを do-not-merge から ready-for-review. に変更します

PR で主なアクションを実行するには、次の表のコメントを使用します。

ハッシュタグ コメント	できること
#sign-off	ready-to-merge ラベルを自動的に割り当てて、リポジトリのレビュー担当者に、レビュー/マージの準備が PR にできていることを通知します。 リストされている作成者では "ない" 場合、#sign-off コメントを使用してパブリック リポジトリの PR をサインオフしようとすると、PR が更新されて、ラベルを割り当てることができるのは作成者のみであることが示されます。
#hold-off	気が変わったか、間違えた場合に、ready-to-merge ラベルを削除します。
#please-close	変更をマージしないと決めた場合に、PR を閉じます。
#please-open	閉じた PR または問題を再度開きます。

変更をマージするには、コメント「#sign-off」を入力する必要があります。 すべてのレビューと検証チェックに合格した場合でも、作成者が、このコメントを使用して、PR レビュー担当者とリポジトリ管理者に変更をマージする準備ができていることを通知する必要があります。 レビュー担当者が PR に問題がないと判定し、サインオフすると、変更が親ブランチにマージされ、PR が閉じられます。

発行

次回にスケジュールされている発行の実行に変更を含めるには、PR レビュー担当者が PR をマージする必要があることに注意してください。 通常、PR のレビューとマージは申請順に行われます。

投稿が承認され、マージされると、発行プロセスに追加されます。 投稿するリポジトリを管理しているチームに応じて、発行の頻度が異なる可能性がありますが、通常、平日は毎日 1 回以上発行されます。 発行後、記事がオンライン表示されるまで最大 45 分かかります。

変更が発行されると、Microsoft Learn で一般公開され、他のユーザーがそこから学習できるようになります。

シナリオ: Azure App Service に変更を発行する

過去の経験を活かして、役立つ情報を App Service ドキュメント ページに追加する機会を見つけ、変更を追加するための PR を作成しました。 これで、編集内容を発行するための PR のレビューとサインオフの準備ができました。