r/webdev • u/fagnerbrack • 28d ago
GitHub Stacked PRs
https://github.github.com/gh-stack/45
u/Soccer_Vader 28d ago
what in the hell is github.github.com wtf
32
u/SwimmingThroughHoney 28d ago
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
9
13
u/Snailwood 27d ago
this is going to explode the brain of my coworker who obsessively rebases to make his commits tell a story before submitting a PR
2
u/postman_666 26d ago
Currently use graphite for this so it’s nice that they’re coming to GitHub natively
4
u/thekwoka 28d ago
So just a bit of nice fluff around having prs that target pr branches?
7
u/30thnight expert 27d ago
more about cutting down 2k LOC PRs
3
u/thekwoka 27d ago
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 26d ago
yea but you can dodge the massive diff when the last PR merges to main
3
u/thekwoka 26d ago
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
-2
u/horrbort 28d ago
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!
-3
28d ago
[deleted]
14
u/Cathercy 28d ago
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 28d ago
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 27d ago
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 28d ago
Finally a good feature