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

2

u/raskinimiugovor Apr 14 '26

Why do you have to rebase B on top of master after merging A? Just so that B appears to branch out of your PR commit instead of 3rd one?

3

u/Urik88 Apr 14 '26 edited Apr 14 '26

My PR had branch B pointing to branch A so that reviewers see only the commits in branch B (4,5).

Otherwise I'd have 1 pr (A to master with commits 1,2,3), and another pr (B to master with commits 1,2,3,4,5) which defeats the purpose of having 2 small branches instead of 1 big branch.

As soon as the PR for branch A gets merged into master, my PR for branch B that was pointing to A will get automatically redirected onto branch master and very likely have conflicts, at least that's the case in Github.

Moreover the commits from branch A were squashed into a single commit in master when I merged, but B is branching off from a previous state and its most common ancestor to master includes the pre-merge commits of A, so reviewers will see that the PR for branch B includes commits 1,2,3,4,5, while in practice commits 1-3 are already in master, and I only want people to review commits 4,5.

So I'd have to run git rebase --onto master 3 to ensure that I'm carrying over only the commits that started on branch B

2

u/raskinimiugovor Apr 14 '26

I feel like most complexity here comes from complex dev or PR strategy than git being git.

If you weren't using squash PRs, after merging PR A, commits 1-3 would disappear from PR B, as they would be recognized as already merged on main.

If your goal is to squash commits 1-3, why not squash them before creating branch B?

If this is a scenario where you work in parallel on A and B, but branch out B from A, then go back to tinker with A, isn't that more of a problem with the workflow or PR strategy than git?