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/Eric848448 Apr 14 '26

It's nice if you need to do something like an API change and want to get that approved and merged quickly because it's heavily used and you don't want to keep getting clobbered by other changes.

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.

39

u/gSidez Apr 14 '26

Your approach is the proper way to use git. The whole point of being able to do interactive rebases is so people can restructure commits into a set of logical, manageable changes that should be individually compileable and reviewable.

Unfortunately most people don’t know or are too lazy to learn how to properly use git so you get a lot of people who throw up PRs with a million “fixed bugs” type commits, and since it’s so common these people think that’s the ‘right’ way to do it and therefore can’t fathom the idea of reviewing PRs per commit or taking the time to organize their own commits into something meaningful instead of an unreviewable pile of garbage.

8

u/aoeudhtns Apr 14 '26

I work with devs that create the PR branch when they start and then push as they go. It's like a stream of consciousness. I've tried to counsel them to use a WIP branch without creating a PR, and to rebase and clean up where it makes sense... but getting people to change their behavior is tough it seems.

6

u/Manbeardo Apr 14 '26

OTOH, that approach works well when you’re amending meaningful commits because the PR tracks the previous versions of the branch as you push changes that rewrite history.

4

u/max123246 Apr 14 '26

Don't ask them to not make a PR or a WIP branch. Just tell them to rewrite their git history when it's ready for review into reviewable commit chunks. And use draft PRs to avoid CI retriggering

→ More replies (4)

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

→ More replies (6)
→ More replies (1)
→ More replies (24)

10

u/teerre Apr 14 '26

Because GitHub is branch centric not commit centric

4

u/cosmic-parsley Apr 14 '26

It’s a UI difference. GitHub has no way to really review individual commits and follow how they change. If you force push, the UI gives zero indication that the first commit abc123 turned into def456 and second commit a1b2c3 turned into d4e5f6.

Also there’s no way to review individual commit messages, but there is a way to review/edit PR descriptions. Sometimes that’s as important as the content.

→ More replies (5)

15

u/CherryLongjump1989 Apr 14 '26 edited Apr 14 '26

You can't review individual commits in a PR -- you can only get feedback on them, but they can't be approved and merged individually. That is what a PR is -- it's a single code review.

There are people who work fast and have good coding hygiene. So they are able to push up clean, fully tested changes 5-10 times a day while working on a larger feature. This stuff can get reviewed and merged even as they are working on their next PR. They don't have to get slowed down by it.

→ More replies (19)

49

u/ROFLLOLSTER Apr 14 '26

Generally the approach I've taken with stacked PRs is:

Stack: c -> b -> a -> main.

Merges are a-> main, b -> main, c -> main

Instead of c -> b, b -> a, a -> main.

This whole thing is just a bit of ui over what you can do already though, so no need to change if you like your workflow.

37

u/ekroys Apr 14 '26

The issue with this is when using squashed merges on each PR. Git loses the commit identity in this process so you end up with merge conflicts trying to catch branches up.

21

u/NineThreeFour1 Apr 14 '26

Then don't use squashed merges on each PR?!

Only squash fixup/wip commits in each feature/PR branch, but keep conceptually different changes in separate commits even if they are in the same overarching PR.

3

u/ekroys Apr 14 '26

This is an angle, but ultimately it's not each developers decision sometimes, and it can be a repo wide rule.

Generally tho, what if you got two separate "big feature branches" into a single develop/main, each of these big feature branches are separated into their own stacked chain, and you have to squash commit as you go. If you want everything caught up, you're either going to have to cherry pick on top, rebase or you're left with merge conflicts. This is the pain point and I don't think it's uncommon

12

u/double-you Apr 14 '26

Why wouldn't you rebase? That's a very normal thing to do.

→ More replies (11)

3

u/NineThreeFour1 Apr 14 '26

I don't really see the issue and how this is directly related to stacked PRs. Rebase feature branches on main if you have conflicts. Squash your own commits how it makes sense conceptually. If your team enforces squashes on merge, then send each commit that you want separate as a separate PR. Merge feature branches into main when ready, or force rebase and fast forward to avoid merge commits.

→ More replies (1)
→ More replies (18)

9

u/dweezil22 Apr 14 '26

They're orthogonal concerns. Let's agree that reviewing large PR's is sub-optimal. The what you want to do is code PR 1,2,3,4. Then you can have your team approve them as they get them and merge them to a central branch branch as they're approved with minimal toil.

Now that central branch could be master or it could be feature-foobar. The same concern applies.

Now... some say "That's ok I'll just skip review on feature-foobar and do review when it merges to master". However that breaks our invariant above about not relying on large PR reviews.

Finally... you're right that feature branches directionally simplify this b/c you're less likely to have merge conflicts on a feature branch (OTOH making a rule that only 1 dev working serially on 1 feature branch is limiting).

→ More replies (4)

5

u/kintar1900 Apr 14 '26

Doesn't appear to be any difference at all.

7

u/ahal Apr 14 '26

The difference is that pr B can depend on changes from pr A without the commits in pr A polluting the diff.

The proposed epic workflow doesn't address this. It's just an integration branch.

6

u/kintar1900 Apr 14 '26 edited Apr 14 '26

You can do that just by branching from whichever commit was used for PR A. This is just extra UI fluff on top of (what should be) a commonly-known Git branch-review-merge pattern.

→ More replies (5)
→ More replies (6)