I’ve reviewed stacked PRs a couple of times and found it pretty terrible. The only one that ends up making any sense is the first. Better off with either just one single big PR, or don’t ask anyone to look at the next PR until the first one is merged.
At my company we use git squash PR merge strategy. This makes individual commits irrelevant, but PRs as a whole do. I use git town for stacked PRs. It's very nice to do another brunch when I've finished a logical stage, because small changes are reviewed and I merge often. When I have fixes, "git town sync" propagates up the stack automatically
Comments
https://graphite.dev/ provides a way to stack PRs, it's been discussed on HN in the past (e.g. https://news.ycombinator.com/item?id=30681308).
I’ve reviewed stacked PRs a couple of times and found it pretty terrible. The only one that ends up making any sense is the first. Better off with either just one single big PR, or don’t ask anyone to look at the next PR until the first one is merged.
At my company we use git squash PR merge strategy. This makes individual commits irrelevant, but PRs as a whole do. I use git town for stacked PRs. It's very nice to do another brunch when I've finished a logical stage, because small changes are reviewed and I merge often. When I have fixes, "git town sync" propagates up the stack automatically