pull request を使用して共同作業する
プル要求を使用すると、GitHub リポジトリにプッシュした変更について他のユーザーに通知できます。
プル要求が送信されると、関係者は一連の変更を確認し、潜在的な変更について話し合い、必要に応じてフォローアップ コミットをプッシュすることもできます。
プル要求は、共有リポジトリ モデルを使用して共同作業を行うチームや組織でよく使用されます。
すべてのユーザーが 1 つのリポジトリを共有し、トピック ブランチを使用して機能を開発し、変更を分離します。
GitHub の多くのオープンソース プロジェクトでは、pull request を使用して共同作成者からの変更を管理します。
変更についてプロジェクトの保守担当者に通知する方法を提供するのに役立ちます。
また、メイン ブランチにマージする前に、一連の変更に関するコード レビューと一般的なディスカッションを開始します。
pull request では、コードのレビューとマージが組み合わせられて、1 つのコラボレーション プロセスになります。
ブランチのバグまたは新機能の修正が完了したら、新しい pull request を作成します。
チーム メンバーを pull request に追加して、変更を確認して投票できるようにします。
pull request を使用して、進行中の作業をレビューし、変更に関する早期のフィードバックを得ます。
所有者はいつでもプル要求を破棄できるため、変更をマージするコミットメントはありません。
コードを確認する
プル要求で行われるコード レビューは、バグを見つけるだけではありません。これは、テストが関連する内容です。
優れたコード レビューでは、後でコストのかかる問題につながる可能性がある、あまり明確でない問題をキャッチします。
コードレビューは、不適切なマージやビルドの失敗によるチームの生産性低下からチームを守るのに役立ちます。
レビューでは、マージの前にこれらの問題をキャッチし、不要な変更から重要なブランチを保護します。
コード レビューで幅広いレビュー担当者を使用して、専門知識を相互に受粉し、問題解決戦略を広めます。
スキルと知識を拡散することで、チームの堅牢性と回復力が向上します。
優れたフィードバックを提供する
高品質のレビューは、高品質のフィードバックから始まります。 pull request で優れたフィードバックを得る鍵は次のとおりです。
- 適切なユーザーに pull request をレビューしてもらう。
- 校閲者がコードの動作を把握していることを確認します。
- 実用的で建設的なフィードバックを提供します。
- コメントに速やかに返信します。
pull request にレビュー担当者を割り当てるときは、適切なレビュー担当者のセットを選択してください。
コードのしくみを知っているレビュー担当者が、他の分野で作業する開発者を含め、アイデアを共有したいと考えています。
また、誰が変更の明確な説明を提供し、修正や機能が組み込まれたコードをビルドできるかを示すこともできます。
レビュー担当者は、不一致の変更に関するフィードバックを提供する必要があります。 問題を特定し、別の方法で実行する内容について具体的な提案を行います。
このフィードバックには明確な意図があり、pull request の所有者が理解しやすいものです。
pull request 所有者は、コメントに返信するか、提案を受け入れるか、提案された変更が理想的でない理由を説明する必要があります。
提案が適切な場合もありますが、変更は pull request の範囲外です。
これらの提案を行い、pull request とは別の新しい作業項目と機能ブランチを作成して、それらの変更を行います。
ポリシーを使用してブランチを保護する
リポジトリには通常、main を含む 1 つ以上のブランチが存在し、重要であるため追加の保護が必要です。 Azure Repos には、この目標を達成するために実装することを検討する必要があるポリシーベースのメカニズムがいくつか用意されています。
これらのメカニズムの基本的な前提は、プル要求に制約を適用することです。 たとえば、プル要求をマージする前に、指定されたレビュー担当者からの承認の最小数を要求するなど、特定のコード レビュー ポリシーの適用を含めることができます。 コード変更の品質と信頼性を高めるために、集合的な専門知識を活用する必要があります。
さらに、リンクされた作業項目のチェック ポリシーを実装することを検討してください。 これにより、すべてのプル要求が作業項目にリンクされ、コンテキストが提供され、追跡可能性が促進されることを確認します。 コメント解決の確認ポリシーは、pull request をマージする前にすべてのコード レビュー コメントに確実に対処するのに役立ちます。
自動コード分析、テスト、コンプライアンス チェックに関連するポリシーにより、統合前に変更が定義済みの標準を満たしていることを確認できます。 マージの種類を制限すると、制御ブランチ履歴を維持するのに役立ちます。 たとえば、リベースとスカッシュマージのみを許可するオプションがあります。
新しいコードバージョンのクリーンビルドを行うことを必須とした上で、重要なブランチにマージすることも可能です。 これにより、マージされた変更によってビルドエラーや回帰の問題が発生しないようにします。 状態チェックを使用すると、外部サービスによって生成されたシグナルに応じてプル要求を完了できます。 たとえば、このようなシグナルは、自動テストとコード分析を実行する Azure Pipelines によって生成できます。
必要なポリシーが構成されているブランチでは、ダイレクト プッシュが自動的にブロックされ、すべての変更に対するプル要求が効果的に適用されます。 また、このようなブランチは削除できません。