プル要求では、コードのレビューとマージを 1 つのコラボレーション プロセスにサポートします。 開発者は、機能またはバグ修正を追加すると、プル要求を作成して、変更をアップストリーム ブランチにマージするプロセスを開始します。 その後、他のチーム メンバーには、最終版の前にコードを確認して承認する機会が与えられる。 pull request を使用して、進行中の作業をレビューし、変更に関する早期のフィードバックを得ます。 ただし、変更をマージするコミットメントはありません。 所有者はいつでもプル要求を破棄できます。
コードのレビューを取得する
pull request の一部として行われるコード レビューは、明らかなバグを見つけるだけではありません。それがテストの目的です。 適切なコード レビューでは、後でコストのかかる問題につながる可能性がある、あまり明確でない問題をキャッチします。
コード レビューは、不適切なマージや壊れたビルドによってチームの生産性が損なわれることを防ぎ、チームを保護するのに役立ちます。 レビューでは、マージの前に問題がキャッチされ、不要な変更から重要な分岐が保護されます。
また、コード レビューは、開発者間のコラボレーションとコミュニケーションを促進し、強化します。 チームは、メイン ブランチと機能ブランチの間で行われたすべての変更の明確な履歴を取得します。
コードレビューに様々なレビュアーを参加させることで、専門知識を共有し、問題解決戦略を広げましょう。 スキルと知識を拡散することで、チームは強くなり、回復力が高まります。
優れたフィードバックを提供する
高品質のレビューは、高品質のフィードバックから始まります。 pull request で優れたフィードバックを得る鍵は次のとおりです。
- 適切なユーザーに pull request をレビューしてもらう。
- 校閲者がコードの動作を把握していることを確認します。
- 実用的で建設的なフィードバックを提供します。
- コメントにタイムリーに返信します。
pull request にレビュー担当者を割り当てるときは、必ず適切なレビュー担当者のセットを選択してください。 校閲者はコードのしくみを知っている必要がありますが、他の分野で作業する開発者も含まれているので、アイデアを共有できます。
変更の明確な説明を入力し、修正プログラムまたは機能が動作するコードのビルドを提供します。 レビュー担当者は、同意しない変更に関するフィードバックを提供するよう努力する必要があります。 問題を特定し、別の方法で実行できる内容に関する具体的な提案を行います。 このフィードバックには明確な意図があり、pull request の所有者が理解しやすいものです。
pull request 所有者は、コメントに返信するか、提案を受け入れるか、適用を拒否する理由を説明する必要があります。 一部の提案は適切ですが、プル要求の範囲外である可能性があります。 これらの提案を行い、pull request とは別の新しい作業項目と機能ブランチを作成して、それらの変更を行います。
ポリシーを使用してブランチを保護する
リポジトリには、チームが常に適切な状態にあることに依存する重要なブランチがいくつかあります ( main ブランチなど)。 Teams では、 GitHub や Azure DevOps などのプラットフォームを使用して、これらのブランチに変更を加えるためにプル要求を要求できます。 保護されたブランチに変更を直接プッシュする開発者は、プッシュが拒否されます。
プル要求に条件を追加して、キー ブランチで高いレベルのコード品質を適用します。 マージされたコードのクリーン ビルドと複数のレビュー担当者からの承認は、多くの場合、キー ブランチを保護するために使用される追加の要件です。
詳細情報
GitHub には、pull request を使用して 作業の変更を提案する方法に関する広範なドキュメントがあります。
コード レビューで優れたフィードバックを提供し、pull request テンプレートを使用してレビュー担当者にガイダンスを提供する方法について詳しく説明します。 Azure DevOps には、使いやすく、必要に応じてスケーリングできる 豊富なプル要求エクスペリエンス も用意されています。