While I do think devs should aim to keep PRs small (roughly under 500 lines delta), this approach doesn’t strike me as a good way to achieve that. I generally try to think of the smallest (or a small) collection of commits that is reasonable and safe to release (to production!). Sometimes such a delta doesn’t involve end-user-visible changes.
While interesting, this guide is severely outdated. GitHub supports changing the base branch of a PR. While I agree that it’s nice to use stacked PRs, I can’t agree with the approach here, for it advises to merge into PRs, making the history a total mess.
I think the merging they’re talking about is merging changes made in response to review comments “down” into the downstream PRs; they’re then squashing and merging back up the chain, so in the end on master you get the whole series in a single commit.
Oh, I miss the last squashing. But that kind of defeats the whole purpose of having small, isolated commits. Now, when there is an issue in production, and bisect pinpoints to this commit, good luck to whomever needs to deal with it to pinpoint the exact change that caused the failure.
Wasn’t clear to me why the flow wasn’t to go foe small focused PRs in the first place