pull request を使用して共同作業する
pull request を使用すると、GitHub リポジトリにプッシュした変更のことを他のユーザーに知らせることができます。
pull request が送信されると、利害関係者が一連の変更をレビューし、考えられる変更について議論して、必要であればフォローアップのコミットをプッシュすることさえできます。
pull request は、共有リポジトリ モデルを使用して共同作業するチームや組織でよく使用されます。
全員が 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 の所有者は、コメントに返信し、その提案を受け入れるか、または推奨された変更が理想的でない理由を説明する必要があります。
提案は適切なものであっても、変更がその pull request の範囲を外れている場合があります。
変更を行うには、これらの提案を受け取り、その pull request とは別の新しい作業項目と機能ブランチを作成します。
ポリシーを使用してブランチを保護する
通常リポジトリには、重要であるために一層保護を必要とするメイン ブランチなどの 1 つ以上のブランチが含まれます。 Azure Repos には、この目標を達成するために実装することを検討する必要があるポリシーベースのメカニズムがいくつか用意されています。
これらのメカニズムの基本的な前提は、pull request に制約を適用することです。 たとえば、pull request をマージするためには、その前に、指定されたレビュー担当者からの最小数の承認を必須にするなど、特定のコード レビュー ポリシーの適用を含めることができます。 コード変更の品質と信頼性を高めるために、集合的な専門知識を活用する必要があります。
さらに、リンクされた作業項目のチェック ポリシーを実装することを検討してください。 これにより、すべての pull request が作業項目にリンクされ、コンテキストが提供され、追跡可能性が促進されることを確実にできます。 コメント解決の有無を確認するポリシーは、pull request をマージする前に、すべてのコード レビュー コメントに確実に対処するのに役立ちます。
自動コード分析、テスト、コンプライアンス チェックに関連するポリシーにより、統合前に変更が定義済みの標準を満たしていることを確認できます。 マージの種類を制限すると、制御ブランチ履歴を維持するのに役立ちます。 たとえば、fast-forward マージと スカッシュ マージのみを許可する選択肢があります。
また、新しいコード バージョンを重要なブランチにマージすることを許可するには、その前に、クリーン ビルドを必須にすることもできます。 これにより、マージされた変更によって、ビルドエラーや逆行の問題が発生しないようにします。 状態チェックを使用すると、外部サービスによって生成されたシグナルに応じて、pull request を完了できます。 たとえば、このようなシグナルは、自動テストとコード分析を実行する Azure Pipelines によって生成できます。
必要なポリシーが構成されているブランチでは、ダイレクト プッシュが自動的にブロックされ、すべての変更に対する pull request が効果的に適用されます。 また、このようなブランチは削除できません。