| This article implicitly assumes that a single PR corresponds to a single commit. It doesn't touch on the idea of multiple commits in a single PR. Consider adding a feature. I might structure this as three commits: 1. Refactor in a way that preserves existing behavior but prepares for the new feature 2. Implement the feature, creating a user-visible change 3. Remove old code rendered unnecessary with the new feature Each of these commits is independently reviewable, passes all lints and tests, and supports bisecting. Small, separate commits like this is good. But there's no rationale for three small, separate PRs, because they are not independent. Either all the commits should land, or none of them. If we later revert, we would revert them all. And review is made easier by seeing how the commits relate to each other. I suspect that structuring PRs as multiple independent commits requires a certain level of git history-grooming which is difficult to learn. If git's interactive rebase were more first-class, we would have fewer, larger, and better-structured PRs. |
It doesn't?
As for the rest of your comment, this is why we have feature flags. What you're describing should be a single PR. I don't care how many commits it is.