Use branches. Branches are cheap in Git, and you can do PRs between branches so that the reviewers are only seeing the new changes in that branch.
In your example, I'd create a branch for R1, and publish a PR for R1 -> mainline when it's ready. Then I create a branch for R2 from the R1 branch, using R1 as the upstream.
When R2 is ready, I publish a PR for R2 -> R1, and create a branch for R3 to start working on it.
When there is feedback for R1, I switch to that branch and make those changes. I'll squash those changes back into the original commit(s) of R1, and update the PR.
Then you rebase R2 with the changes you made from R1, rebase R3 with the changes from R2, etc.
As long as the changes between each branch are not on the same lines of code, the rebases are painless and quick.
I name the branches with a key to support ordering, something like:
In your example, I'd create a branch for R1, and publish a PR for R1 -> mainline when it's ready. Then I create a branch for R2 from the R1 branch, using R1 as the upstream.
When R2 is ready, I publish a PR for R2 -> R1, and create a branch for R3 to start working on it.
When there is feedback for R1, I switch to that branch and make those changes. I'll squash those changes back into the original commit(s) of R1, and update the PR.
Then you rebase R2 with the changes you made from R1, rebase R3 with the changes from R2, etc.
As long as the changes between each branch are not on the same lines of code, the rebases are painless and quick.
I name the branches with a key to support ordering, something like:
1_add_dependencies 2_add_scaffolding 3_feature_A 4_feature_B
This way they show up sorted when you list branches, and it's obvious what their dependency ordering is.