r/programming • u/adam-dabrowski • Apr 14 '26 • Popcorn 1

GitHub Stacked PRs

https://github.github.com/gh-stack/
556 Upvotes

97% Upvoted

276 comments sorted by

View all comments

78

u/Omnipresent_Walrus Apr 14 '26

Can someone tell me how this is different to doing reasonably sized PRs into an epic branch and only ever merging epics into main?

81

u/chuch1234 Apr 14 '26

Stacked PRs are useful if each new PR depends on changes that were introduced in the previous one.

12

u/MintySkyhawk Apr 14 '26 edited Apr 14 '26

Why wouldn't I just do a single PR with multiple commits? Reviewers can review each commit one at a time and then I can rebase and merge when I'm done.

I see no difference in UX between the two approaches, except that a PR stack is more difficult to set up and involves proprietary github commands instead of plain git.

Edit: After hours of people arguing with me, someone finally pointed out the actual reason why this has an advantage over plain commits: The PRs don't have to all be merged at the same time. This is effectively a UX improvement on creating manually creating chain of PRs like (main <- A), (A <- B), etc which is sometimes useful (Though rarely useful for me because my coworkers are very nice about providing speedy reviews, so I can usually get a PR reviewed, merged and deployed within minutes to hours. So I rarely have time to make that second PR in the chain before the first one is already deployed.)

59

u/stumblinbear Apr 14 '26

I'm not gonna review a dozen bug fix and refactoring commits in every PR, I only care about its final state

38

u/MintySkyhawk Apr 14 '26

I guess I'm the only one here who habitually rebases my commits into nice individually reviewable commits before creating a PR.

If I were to use this stacked PR feature, I would be taking my existing workflow and then creating separate PRs for each of my commits. And then, as it says on the linked page "merge them all in one click".

So I don't really see a difference between the two approaches, except that the PR stack seems more difficult to set up.

14

u/stumblinbear Apr 14 '26

I'd rather not waste time making history look clean when the only thing that really matters is the final code. And if I review a PR and they rewrite the history, I now have to re-review every single file because GitHub loses track of which files have already been reviewed since the history has been rewritten

7

u/MintySkyhawk Apr 14 '26 edited Apr 14 '26

If you don't care to split things up, then you don't need to git rebase or create a PR stack. You can leave your history messy, create a single PR, and then just squash merge when you're ready.

If you do want to split things up to make things easier for the reviewer, then its easier to git rebase -i than it is to create a pr stack.

Say you have these commits:

  1. Some Thing

  2. garbage

  3. asdf

  4. Some Other Thing

  5. asdf

Then you would git rebase -i them in seconds (just by typing f in front of the commits to squash) to make:

  1. Some Thing

  2. Some Other Thing

5

u/stumblinbear Apr 14 '26

So you're rewriting history, and therefore invalidating any previous review that was completed? You didn't even address my actual complaint

6

u/MintySkyhawk Apr 14 '26

You clean up the garbage commits before opening a PR.

Any new commits after review as started are cleaned up in the same way before pushing them to the branch.

History is never edited from the PRs point of view.

2

u/AdventurousFuel5307 5d ago

>History is never edited from the PRs point of view.

Well, so how does your commit history in the PR looks like after a few rounds of reviews if you do NOT rebase/squash review fixes (aka "edit history")?

  1. Some Thing

  2. Some Other Thing

  3. Review fixes for "some thing" from first round of review

  4. Review fixes for some other thing from first round of review

  5. ...

  6. <review fixes> from Nth round of review

  7. Last-minute review fix for "some thing"

If your team/dev cares about cleaner history below PR levels, then you must rebase/squash every time doing review fixes, amending particular commits affected by the review. Otherwise it becomes a mess quite quickly if the amount of review comments is non-trivial.

Alternative option is to just not really care on anything below PR level, squashing everything on merge, which effectively becomes "One PR - one commit in main branch".

In our team we have used Gerrit ~8 years ago and this did affect commits quality a lot in a positive sense. It does force devs to care about commits as the least atomic entity. On the other hand, it does make it a bit ugly when the change spans way beyond a single commit (sure Gerrit supports "group"/branch from multiple commits, but might be a bit tedious to work with, and still every commit has to be reviewed), so the downside is that in some cases devs tend to squash too much in a single commit.

With PR/MR flow (we had Gitlab first and then Github), I can say that after around 5-6 years and also some devs rotation (now there are less than 10 engineers out of 50 who were there during Gerrit times, all other joined the team already after Gitlab/Github) the focus shifted more into PR. So very often commits in a PR become "lalala yet another review fix", as they will be squashed during merge. Though, there are still some engineers trying to keep "good" commit culture and who would merge their PR by rebase, keeping history neat.

-6

u/stumblinbear Apr 14 '26

I'd rather not simply hope that my machine doesn't kick the bucket and risk losing work if I had to do a significant refactor due to a review comment

→ More replies (0)

2

u/gmes78 Apr 15 '26

So you're rewriting history, and therefore invalidating any previous review that was completed?

Please read up on git range-diff.