3 ms·

I think the idea is that in a branch after a rebase, you have “main” with your new branch commits on top. This is exactly what it’d be like after merging to mai

I think the idea is that in a branch after a rebase, you have “main” with your new branch commits on top. This is exactly what it’d be like after merging to main, so you can test the branch with a high degree of confidence it’ll work correctly after merging.

MereInterest 4y ago
Yes, but that only says that rebasing is no worse than merging with respect to testing the branch ahead of time. With respect to identifying when a bug was introduced, or the intended effect of a change, rebasing is worse because it cannot distinguish between a bug introduced during a feature implementation and a bug introduced during the rebase. The history that would be needed to distinguish between those cases has been thrown away.
- rgoulter 4y ago
  Even then, it's worth distinguishing between: - Work in progress: My change request has been open for some time; I will rebase it against the master branch. - Accepting changes into master branch: `git merge` or `rebase + commit` or `rebase + squash + commit`. I don't think there's any practical downside to rebasing WIP branches.