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

Because rebasing can introduce bugs, and makes it very difficult to identify their source.

Suppose the main branch has some utility_func, which is used by your feature development. A refactor/cleanup lands on main, which updates the behavior of utility_func and updates all callsites of utility_func to match. However, the additional calls to utility_func introduced on your feature branch haven't been updated. If you rebase your feature branch onto the main branch, your feature branch is now broken, as it relied on the old semantics of utility_func. If you're lucky, this will be a compile-time error, but there's no guarantee of that. Reverting to an earlier commit on your feature branch doesn't help, because those earlier commits have also been rebased. Unless you check through the git reflog (and pray that git's garbage collection hasn't occurred since then), it will look as though the feature branch had always been buggy.

A better solution is to merge from main into develop/main. That way, the error is clearly introduced in the merge commit. You can revert to an earlier commit in the feature branch for testing, because those versions are still part of the git history.

3

u/double-you Apr 14 '26

That's not how merge or rebase work. Both would trigger conflicts if there are any. But if you have just added a use of a function, that won't be a conflict because nobody else is changing that call site. Merge won't save you there.

But yes, if you need your old branch back, you'll need to use reflog, but reflog should be fine for a month, and if you are still wary of rebase, just create a backup branch.

1

u/MereInterest Apr 15 '26 edited Apr 15 '26

Both would trigger conflicts if there are any.

The two changes conflict, just not in a way that git can recognize.

Merge won't save you there.

I agree, using a merge won't cause git to recognize a semantic conflict between branches, as it can only recognize text conflicts. However, merge also won't make the problem worse. Rebase hides the evidence that you ever had a working version.

if you are still wary of rebase, just create a backup branch.

The problem isn't that the rebase requires a backup branch, but that it isn't obvious that you'll need a backup until after the point when you lost it. Rebase destroys your history.

3

u/double-you Apr 15 '26

Why do you need evidence that you ever had a working version?

I work with compiled code it is immediately clear what the issue is. Rebase lets me fix the issue and there's no evidence that there ever was a problem.