レポジトリーの「Branch Protection」が設定されている前提の話すですが、GitHubのレビュー機能を使ってPull Requestに対して「Changes Requested」、つまり「修正が必須」というレビューが出された場合、そのレビューを出した本人が「Approve」（承認）を出すまで、マージできなくなります。
これは、安全性を考えた便利な機能ではありますが・・・
運用していると、「修正頼んだ人がいないのにリリースしないといけない！」なんてことは、やはりあります。
逃げ道
「Branch Protection」の設定次第ではありますが、「人のレビューをオーバライドしてマージさせる」方法があります。
マージ拒否になったPull Requestの画面に、赤い×が付いているレビューの横に小さく「Dismiss review」という文字があると思います。
この文字をクリックすると、該当レビューを「ただのコメント」に変えられちゃいます。
人のレビューをほぼ、「なかったこと」にする事なので、ちゃんとその理由を書いておかないと行けませんし、気軽にやっていい作業ではないと思います。
そして、「Branch protection」の設定によっては、この作業ができる人が限られている可能性があります。
その場合、権限を持ってる人に頼んで、もう一度レビューをもらい、依頼された修正が反映されていることを確認してもらって、×となってるレビューをDismissしてもらいましょう。
ちなみに、Dismissされたレビューのコメントなどは全て残りますので、後で見返すことなども出来ます。
まあ、リリースの前日ぐらいに、PRを修正して、レビューしてくれた人に確認取る方がいいと思いますが、そうは行かないこともあるし、緊急事態は、緊急事態なので、抜け道を紹介しました。
※DismissについてのGitHub本家のhelpです：
おまけ：実際の運用体制
ちなみに、うちの会社ではほぼ全てのブランチにprotection設定をつけていて、レビューがApproveされることを必須にしています。そして、レビューのDismiss権限は4人しか持っていません。
若手などが多いチームだとその方がお互いに安心だったりしますし、deployの事故とその後遺症から若手を守れますので、おすすめです。