一つの機能を実装する際に、プルリクエストを分割して出すことでレビュアーの負担を減らそうという提案です。
下記の図のイメージです。
背景
プルリクエストを程よい粒度で分割できれば良いので、わざわざこんな回りくどいことをせず、基本的には直接masterブランチなりに適度にプルリクエストを出せば良いと思います。
図の例のようにUIだけ実装している時などに、masterにマージすると変な状態のコードがリリースされてしまってマズいという場合があり、そういう場合のプルリクエスト運用の提案になります。
デプロイ可能な単位でmasterにマージしたいが、プルリクエストは適度に分割したい、という感じです。
どの開発現場でも起きうる結構普遍的な問題なのかと思っているのですが、調べてみたら今回のような具体的な手法みたいなのがあまり見当たりませんでした。
これ絶対既に誰かやってると思ったんですが... 
私が知らないだけで、
- 既にこのやり方に名前がついていたり
- もっとスマートなやり方があったり
- 「うちではこんな感じにやっていて、いい感じに回ってるよ！」
などの情報があれば是非教えてください！
やってみた
まだこれから試していく、という段階です。
1回だけこのフローでプルリクを出したのですが、レビュアーの方には「やりやすくて良かった」という旨の言葉を頂けました。
また、この案では最初に空コミットをするので、このWIPパターンと組み合わせてプルリクを出したりしました。
Work in ProgressパターンによるPull Requestを利用した開発フロー
調べてみた
こういうやり方は既に世に出回っているだろうと調べたメモを書いておきます。
参考1
「巨大プルリク1件vs細かいプルリク100件」問題を考える（翻訳）
10 lines of code = 10 issues.
500 lines of code = "looks fine."
Code reviews.
記事内で↑こちらのツイートが引用されていましたが、私も身に覚えがありますし、こういったことが起きないように巨大なプルリクエストはできるだけ避けたいと考えています。
具体的には下記のアプローチが書いてありました。
- 「早期」かつ「頻繁に」
- 粒度を小さくする
- 作業のスコープを絞る
上部の図の例だと、ui と api というスコープ分割してレビューがしやすくなり、分割されたことでプルリクの粒度も小さくなっています。
参考2
記事内で Issueの単位とPRの単位は違う ということを書かれています。
これは巨大プルリクを減らすためには良い考え方だなと思いました。
漠然とそうあるべきだよなーみたいなことは思っていた気がしますが、ちゃんと明文化しておくことが大事だなと思いました。
細かい方法はやり方は私の案のものと異なりますが、概ね同じようなアプローチなのかなーと思って読みました。
まとめ
巨大なプルリクはレビュー辛い 