プルリクエストの作成者がマージする必要があるコードレビューワークフロー

私の会社のいくつかのチームは、今まで見たことのないコードレビューワークフローを実践しています。会社全体の一貫性を保つことには価値があるという考えで、その背後にある考え方を理解しようとしています。（私は複数のコードベースに貢献しており、過去の違いにつまずいたことがあります。）

1. コード作成者がプルリクエストを送信する
2. レビュアーはコードを調べます
3. • レビュー担当者が承認すると、「よさそうだ、気軽にマージしてください」という行に沿ってコメントを残します
   • レビューアに懸念がある場合は、「マイナーな問題XおよびYを修正してからマージしてください」などのコメントを残します（大きな変更については、手順2に戻ります）
4. コードの作成者は、必要に応じて変更を加え、自分のプルリクエストをマージします

次の懸念事項があります。

• ステップ3での承認の場合、このワークフローはプルリクエストの作成者に対して一見不必要なラウンドトリップを作成します。すでにコードを見ているレビューアは、ただちにコードをマージできます。

• ステップ3で変更が要求された場合、プルリクエストをマージする機関は、PRの作成者のみに任されています。著者以外の誰も、マージする前に変更を見ません。

このワークフローのその他の長所と短所は何ですか？このワークフローは他のエンジニアリングチームで共通ですか？

最初のケースでは、通常は礼儀です。ほとんどの組織では、マージは一連の自動化されたテストを開始し、それらが失敗した場合はすぐに対処する必要があります。特に、プルリクエストが送信されてからレビューされるまでに大幅な遅延が発生した場合、作成者のタイムテーブルにマージできるようにすることは礼儀です。それを行う最も簡単な方法は、自分でマージできるようにすることです。

また、作者は、プルリクエストをまだマージしてはいけないという理由を後で知っていることがあります。別の開発者のPRの方が優先度が高く、競合が発生する可能性があります。たぶん、彼女は明らかにされたユースケースについて考えました。レビューのコメントがブレインストーミングを引き起こし、問題が完全に満たされる前にさらなる調査が必要な場合があります。作成者はコードについて最もよく知っているので、いつマージされるかについて最後の言葉を与えるのは理にかなっています。

2番目の点では、それは単なる信頼の問題です。人々を再確認せずに小さな問題を修正することを信頼できない場合、彼らはあなたのために働くべきではありません。問題が修正後に別のレビューを必要とするほど大きい場合は、レビュー担当者に信頼してもらいます。

そうは言っても、私は時々他の著者のプルリクエストをマージしますが、通常は非常に単純な変更か、外部ソースからのものであり、テスト自動化の失敗をシェパーディングする責任を個人的に負います。

最初の作成者に独自のプルリクエストをマージさせることは、小さなチームでの私の好みのワークフローです。既に述べた技術的な利点（たとえば、マージの競合を解決するという点）に加えて、文化レベルでの価値を高めると思います。それは所有感を構築します。

別の開発者がオープンプルリクエストにコミットを追加する（まれな）ケースの最初の作成者を指定しました（進行中の機能ブランチをプルしてプッシュバックします）。これは頻繁には発生せず、直接の会話またはSlackでの会話の結果として発生します。これらの追加のコミット（他の誰かによる）は、驚くことではありません。この文脈では、最初の著者とは、プルリクエストを送信した人を意味します。

私の組織では、プルリクエストがまったく新しいので、あなたの質問は私が熟考したものです。

私が追加したい観察事項：いくつかのツール（TFSを使用）では、プルリクエストに関連付けられたワークアイテムがある場合があります。

その場合、レビュアーがマージを実行した時期を追跡するのは少し面倒になります。そのシナリオでは、開発者はPRを再訪し、バグまたは変更要求を開き、「解決済み」としてマークする必要があります。早期に「解決済み」とマークすると、テスターは修正が現在のビルドの一部であると信じています。

TFS 2017では、プルリクエストの実装が改善されました。これで、開発者は、すべての条件が満たされた場合に自動的にマージするようプル要求を要求できます（マージの競合、レビュアーからの承認、および破損したビルドはありません）。YMMV。

このようにして、著者は自分のブランチについて考えを変える機会があり、別の方法で行うべきことを考え出し、レビューのために追加料金を元に戻すことができます。