On any code base I've worked on that's larger than a small FOSS project, I've found that this simply isn't avoidable. Yes, there's merge commits but, for reasons I won't go into, I think those are worse than the alternative of rebasing and making code reviews difficult.
> One way to avoid this is to push new commits addressing the review comments, and then after the PR is approved do a rebase to reorganize everything.
Not realistic when working on a code base where PRs are being squash-merged every hour and the code review lasts for days.
The best middle-ground is to avoid rebasing until the current wave of feedback has been resolved, even if no one has actually approved yet.
> Not realistic when working on a code base where PRs are being squash-merged every hour and the code review lasts for days.
But if they collide, you have to resolve all the merge conflicts anyway, and then with rerere you should have relatively little additional work on the final rebase.
On any code base I've worked on that's larger than a small FOSS project, I've found that this simply isn't avoidable. Yes, there's merge commits but, for reasons I won't go into, I think those are worse than the alternative of rebasing and making code reviews difficult.
> One way to avoid this is to push new commits addressing the review comments, and then after the PR is approved do a rebase to reorganize everything.
Not realistic when working on a code base where PRs are being squash-merged every hour and the code review lasts for days.
The best middle-ground is to avoid rebasing until the current wave of feedback has been resolved, even if no one has actually approved yet.