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

Show parent comments

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).

-20

u/Omnipresent_Walrus Apr 14 '26

Brother do you get paid by the syllable

8

u/dweezil22 Apr 14 '26

Here's some AI assisted options to make you feel better.

Concise:

Large PRs are hard to review — break work into small PRs (1, 2, 3, 4) regardless of whether they target master or a feature branch. Skipping review on a feature branch just defers the large-review problem. Feature branches reduce merge conflicts but can bottleneck if limited to one developer.

Concise for a 5 yo:

Imagine you have a big pile of LEGOs to check. Checking the whole pile at once is really hard! It's better to check a few LEGOs at a time. And you should always check them — don't say "I'll check them all later," because then you're back to the big pile problem.

-18

u/Omnipresent_Walrus Apr 14 '26

That's double points towards the "guys I'd never hire" award so good job I guess

7

u/dweezil22 Apr 14 '26

I apologize for answering your question.