PRレビューでコメントしながら承認する方法

まとめ

• ノンブロッキングコメントを残しつつPRを承認する。Conventional CommentsのラベルでレビュアーのインテントをClear にし、コードの流れを止めない。

ポイント

• Conventional Commentsのラベル（nitpick: / suggestion: / question: / issue (non-blocking):）を使うと、レビュー時点でインテントが明確になり、追加ラウンドが不要になる。
• 「コミット時に承認リセット」や「auto-merge」のリポジトリ設定はこのワークフローを崩すことがある。採用前に設定を確認すること。
• Linter・auto-formatter・型チェッカー・セキュリティスキャナーをCIに入れると些末なコメントが減り、承認がシグナルとして機能しやすくなる。
• コードレビューでブロッキング課題が出るのは、startupやSMBでは単なるコードの問題ではなく、上流での認識ズレが原因であることが多い。
• 目指すのは、フィードバックのほとんどがノンブロッキングで済む「高アラインメントなチーム」であり、comment-and-approveを例外ではなくデフォルトにすること。

Hacker Newsのコメント動向

• 最も鋭い反論はレビュー待ち時間の問題だ。2時間と23時間のターンアラウンドには大きな差があり、2往復目が生じるとコストは複利で膨らむ。
• Azure DevOpsにはこのワークフローに近い「Approve with suggestions」状態がネイティブで存在するが、承認後にコメントが読まれるかは依然として疑問符がつく。
• 経験豊富なエンジニアとテストカバレッジが整った環境では有効との見方が多い一方、ノンブロッキングコメントを適切に処理できないジュニアエンジニアとの組み合わせでは信頼性が落ちるという指摘もある。

注目コメント

• @singron：「レビューが2時間以内に届くか23時間かかるかは全然違う」——承認ステートではなくレビュー待ち時間こそが本当の隠れコストだと指摘。

Original | Discuss on HN

英語版: Commenting and Approving Pull Requests · Original source