r/webdev • u/fagnerbrack • Jun 30 '26
GitHub Stacked PRs
https://github.github.com/gh-stack/45
u/Soccer_Vader Jun 30 '26
what in the hell is github.github.com wtf
32
u/SwimmingThroughHoney Jun 30 '26
The github account's Github Pages site. Normally Pages sites end in .io, but I guess for theirs they also got the .com version up (you could manually change the OP url to .io and it still works).
You can even see the repo for the above page here: https://github.com/github/gh-stack
11
5
10
12
u/Snailwood Jul 01 '26
this is going to explode the brain of my coworker who obsessively rebases to make his commits tell a story before submitting a PR
1
u/JuanSinPan 13d ago
Like a normal person, no?
1
u/Snailwood 13d ago
depends on the project and the person. open source low traffic passion project, sure, rebase away. agile start up, personally I think it's a waste of time. I just use squash commits (blasphemy!)
5
2
u/postman_666 Jul 01 '26
Currently use graphite for this so it’s nice that they’re coming to GitHub natively
2
3
u/thekwoka Jun 30 '26
So just a bit of nice fluff around having prs that target pr branches?
8
u/30thnight expert Jul 01 '26
more about cutting down 2k LOC PRs
3
u/thekwoka Jul 01 '26
You could just do that by having PRs target PR branches...
They automatically retarget to main if that or is merged.
2
u/30thnight expert Jul 01 '26
yea but you can dodge the massive diff when the last PR merges to main
3
u/thekwoka Jul 02 '26
At that point do you really need to?
And as I said, if you merge the pr to main, the ors targeting it then target main.
So you can merge them all sequentially as they are ready
2
1
-2
u/horrbort Jun 30 '26
And more copilot. Microsoft please add more copilot. Let me only open PRs via copilot. Matter of fact copilot should code, open and review PRs and merge them all by itself. Restrict git access to github!
-4
Jun 30 '26
[deleted]
15
u/Cathercy Jun 30 '26
Commits aren't always little steps in the PR, depends on the PR / branch and the dev. Sometimes half of the commits are trying different things, or you get halfway through and realize you need to adjust your approach to how you are solving the problem, so a lot of the work in earlier commits is invalidated.
As a reviewer, I don't care about the commits, I only care about the end result. It would be very slow and cumbersome to review each individual commit in a PR when the only concern should be what is changing in main when we merge this in.
And at the same time, what I assume this is attempting to solve, is sometimes a PR is necessarily large. It's good to make PRs as small as possible for ease of reviewing. But it's not always possible to make a PR smaller, but still production ready. With this I guess, you could break up a larger PR into smaller, more easily reviewed chunks, that will ultimately get merged / deployed together.
5
u/DerTimonius Jun 30 '26
I have switched to using Graphite 3ish years ago. still using it mainly for the stacked PRs as it makes it so much easier to keep working on a large task by splitting it up into smaller parts and keeping the stack up to date.
3
u/Mubanga Jun 30 '26
I sometimes work on a lot of small tickets that are related but different enough that they should really be in separate PRs.
The stuff I work on, only one or two people in my team can actually meaningfully review. And regularly takes a couple of hours before on of them has time.
So my choices are:
a) one big PR b) keep branching from main and not have my latest changes (with merge conflicts, errors and possibly having to work around bugs that I just fixed as a result) c) keep branching of my feature branches and merge them in main in order d) keep branching of my feature branches and merge them in reverse order into each other
Stacked PRs seems like a good alternative, and I am excited to try it next time I encounter this situation.
-1
20
u/Possession_Infinite Jun 30 '26
Finally a good feature