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