pull request に関するフィードバックを受け取る

プル リクエストは、コードのレビューと単一の共同プロセスへのマージをサポートします。 開発者が機能やバグ修正を追加したら、プル リクエストを作成して、変更を上流ブランチにマージするプロセスを開始します。 その後、他のチーム メンバーには、コードが完成する前にレビューして承認する機会が与えられます。 pull request を使用して、進行中の作業をレビューし、変更に関する早期のフィードバックを得ます。 しかし、変更をマージするという約束はありません。 所有者はいつでもプル リクエストを放棄できます。

コードをレビューする

プル リクエストの一部として行われるコード レビューは、明らかなバグを見つけるだけではありません。 それがテストの目的です。 優れたコードレビューは、後でコストのかかる問題につながる可能性のある、あまり目立たない問題を発見します。

コード レビューは、チームの生産性を損なう不適切なマージや壊れたビルドからチームを保護するのに役立ちます。 レビューはマージ前に問題を検出し、重要なブランチを不要な変更から保護します。

コードレビューはまた、開発者間のコラボレーションとコミュニケーションを促進および強化します。 また、チームはメイン ブランチとフィーチャー ブランチの間で行われたすべての変更の明確な履歴を取得します。

コードレビューに幅広いレビュー担当者を起用することで、専門知識を相互に受配し、問題解決戦略を広めます。 スキルと知識の普及により、チームはより強くなり、回復力が高まります。

優れたフィードバックを送信する

高品質のレビューは、高品質のフィードバックから始まります。 pull request での優れたフィードバックのための鍵は次のとおりです。

• 適切な人たちが pull request をレビューするようにします。
• レビュー担当者がそのコードで実行する内容を知っていることを確認します。
• すぐに実行できる、建設的なフィードバックを送信します。
• コメントにタイムリーに返信します。

プル リクエストにレビュアーを割り当てるときは、必ず適切なレビュアーのセットを選択してください。 レビュー担当者はコードがどのように機能するかを知っている必要がありますが、アイデアを共有できるように他の分野で作業している開発者も含める必要があります。

変更内容を明確に説明し、修正または機能が機能するコードのビルドを提供します。 レビュー担当者は、同意しない変更についてフィードバックを提供するよう努める必要があります。 問題を特定し、別の方法で何ができるかを具体的に提案します。 このフィードバックには明確な意図があり、pull request の所有者が容易に理解できるようになります。

プル リクエストの所有者は、コメントに返信するか、提案を受け入れるか、提案を適用しない理由を説明する必要があります。 いくつかの提案は適切ですが、プル リクエストの範囲外である可能性があります。 変更を行うには、これらの提案を受け取り、その pull request とは別の新しい作業項目と機能ブランチを作成します。

ポリシーを使用してブランチを保護する

リポジトリには、mainブランチなど、チームが常に良好な状態であることに依存する重要なブランチがいくつかあります。 チームは、GitHub や Azure DevOps などのプラットフォームを使用して、これらのブランチに変更を加えるためにプル リクエストを要求できます。 開発者が保護されているブランチに直接変更をプッシュすると、そのプッシュは拒否されます。

プル リクエストに追加の条件を追加して、主要なブランチでより高いレベルのコード品質を強制します。 マージされたコードのクリーン ビルドと複数のレビュー担当者からの承認は、主要なブランチを保護するためによく採用される追加要件です。

詳細情報

GitHub には、プル リクエストで作業への変更を提案する方法に関する広範なドキュメントがあります。

コード レビューで優れたフィードバックを提供するとプル リクエスト テンプレートを使用してレビュー担当者にガイダンスを提供するについて詳しく読んでください。 Azure DevOps は、使いやすく、必要に応じて拡張できる豊富なプル リクエスト エクスペリエンスも提供します。