[danpalmer]

Alternatively, as small PRs can be hard (depending on codebase, language, etc), you can try to do small commits.

Aiming for each commit telling a logical part of the story, that together make a PR that is easy to review.

Why is this easier than small PRs? Typically PRs can’t break anything. Whether it’s CI or breaking the build on the main branch or breaking the workflow of other devs, normally main needs to be stable and PRs are the unit of stable addition to that. However, each commit does not necessarily need to be so, especially if you squash or merge so that there are clear working points to revert to on the main branch.

In many cases my commits might not even compile, but this frees me up to do things like: put bulk renaming or code moves in commits that can mostly be ignored, keep business logic changes in small commits that are easily reviewed, write all test function definitions before filling them in to help summarise the testing that is done, etc. thankfully over the last 4 years or so GitHub’s handling of commit level review on PRs has improved a lot.

Small PRs should still be the goal for many reasons, but when it’s going to take way too much work to do, small commits that lead the reviewer through a story of the change being made can be very effective.