プルリクエストの作成者がマージする必要があるコードレビューワークフロー
私の会社のいくつかのチームが、これまでにないコードレビューワークフローを実践しています。その背後にある考え方を理解しようとしています。会社全体を一貫させることには価値があるという考えです。 （私は複数のコードベースに貢献しており、過去の違いに悩まされてきました。）
- コード作成者がプルリクエストを送信する
- レビュー担当者がコードを調べる
- レビュー担当者が承認した場合、「よさそうです。自由にマージしてください」というコメントを残します。
- レビュー担当者が懸念を持っている場合は、「マイナーな問題XとYを修正してからマージしてください」などのコメントを残します（大きな変更については、手順2に戻ります）。
- コード作成者は必要に応じて変更を加え、自分のプルリクエストをマージします
以下の懸念事項があります。
ステップ3での承認の場合、このワークフローにより、プルリクエストの作成者への見かけ上不要なラウンドトリップが作成されます。すでにコードを見ているレビュー担当者は、すぐにコードをマージできます。
ステップ3で変更が要求された場合、プルリクエストをマージするための代理店は、PRの作成者のみに任されます。マージする前に、作者以外の誰も変更を見ません。
このワークフローの他の利点または欠点は何ですか？このワークフローは他のエンジニアリングチームに共通ですか？
最初のケースでは、それは通常礼儀です。ほとんどの組織では、マージは一連の自動テストを開始します。これらのテストは、失敗した場合に迅速に処理する必要があります。特に、プルリクエストが送信されてからレビューされるまでの間に大幅な遅延があった場合、著者の予定表にマージできるように礼儀正しく、予期しないフォールアウトに対処する時間があります。これを行う最も簡単な方法は、ユーザーが自分でマージできるようにすることです。
また、プルリクエストをまだマージしてはならないという理由を後で作成者が気づく場合もあります。おそらく、別の開発者のPRの方が優先度が高く、競合が発生する可能性があります。たぶん、彼女はカバーされていないユースケースを考えました。おそらくレビューのコメントがブレインストーミングのきっかけになり、問題が完全に満たされる前にさらなる調査が必要になります。作成者はコードについて最もよく知っているので、コードがマージされるときの最後のWordを彼または彼女に与えることは理にかなっています。
第二に、それは単なる信頼の問題です。再確認せずに軽微な問題を修正する人を信頼できない場合、彼らはあなたのために働いているべきではありません。問題が大きすぎて修正後に別のレビューが必要になる場合は、レビュー担当者にレビューを依頼してください。
そうは言っても、他の作成者のプルリクエストを時々マージしますが、それは通常、非常に単純な変更か、外部のソースからのもので、私は個人的にテスト自動化の失敗を回避する責任があります。
最初の作成者が自分のプルリクエストをマージすることは、小規模チームでの私の推奨ワークフローです。すでに述べた技術的な利点に加えて（たとえば、マージの競合を解決することに関して）、それは文化的なレベルで価値を追加すると思います。それは所有権の感覚を構築します。
別の開発者がオープンプルリクエストにコミットを追加する（進行中の機能ブランチをプルしてプッシュする）ときに、initial作成者を指定しました。これは頻繁に起こることではなく、直接またはSlackを介した会話の結果として発生します。これらの追加のコミット（他の誰かによる）はnotに驚かされるはずです！この文脈では、initial作者とは、プルリクエストを送信した人を意味します。
私の組織では、プルリクエストに非常に新しいので、あなたの質問は私が自分で考えたものです。
追加したい所見の1つ：一部のツール（TFSを使用）には、プルリクエストに関連付けられた作業項目がある場合があります。
その場合、レビュー担当者がいつマージを実行したかを追跡するのは少し面倒になります。そのシナリオでは、開発者はPRに再度アクセスして、バグまたは変更リクエストを開き、「解決済み」としてマークする必要があります。早期に「解決済み」とマークした場合、テスターは修正がすでに現在のビルドの一部であると信じています。
TFS 2017では、プルリクエストの実装が改善されました。これで開発者は、すべての条件が満たされた場合（マージの競合、レビュアーからの承認、壊れたビルドがない場合）、プルリクエストに自動的にマージするよう要求できます。 YMMV。
このようにして、作者は自分のブランチについて考えを変える機会があり、おそらく彼は別の方法で行う必要があることを考え出し、追加の請求を見直しのために戻します。