Should you prefer small, incremental changes? Yes. Do you need be pathologically averse to PRs that hit some arbitrary limit? Absolutely fucking not. I just ha

Should you prefer small, incremental changes? Yes. Do you need be pathologically averse to PRs that hit some arbitrary limit? Absolutely fucking not. I just had to do a code refactoring that resulted in 1600 files being deleted. Stacking 40 PRs would have gotten me actually stabbed by my team, and I would have deserved it. Your commits should be atomic, the smallest number of changes to achieve x, where x is a single task that can easily summarized by the commit message. Your PR should contain the smallest number of commits required to achieve y, which is either a minimum viable product to achieve feature z (if z is small enough to be done in one step/PR, good for you), or a step in the path to achieve z. Start your review early (using a WIP/draft PR) if you have the misfortune of having to do a large refactoring so your reviewer(s) can get in on the ground level and review in chunks. If you’re following the rule of “atomic commit” above, it’s really not a big deal for a reviewer to look at changes between each commit which can speed up reviews of big refactorings.