I don't agree that folks who rebase multi-commit branches are "doing it wrong". Even if there are multiple stops along the way, that should not be considered a bad thing if it's understood what it is doing.
The way I look at it, lets say I have 10 commits. If I rebase main, commits 3, 4, 7, 10 have "conflicts" with the code that is on main now compared to when I started writing my feature branch and making commits. But, now, I have an opportunity to update code in each of those commits as if I was writing it based on what is now currently on main. If done like that, incrementally, it usually doesn't cascade into conflicts on each commit.
The problem, IMO, comes when at commit 3, the dev says "Oh, I did this like this in commit 10, so let me just put that solution here in commit 3 to resolve this merge conflict". Now, instead of 4 conflicts, you have conflicts on all of the commits between 3 and 10 (because the dev in effect moved the fix from 10 up 7 commits from where it originally was committed). Instead, each conflict resolution should aim to maintain the code as close to the committed code as possible while integrating the code from main. That way also, the feature branch commits still reflect the iterative process that having multiple commits is designed to show.
I don't embrace a FULL squash rebase, but I do embrace cleaning up your branch commits with an interactive cleanup rebase (not on main, just going through the commits for the branch and squashing any minor fixes that belong with the previous commit, etc.) THEN, once you have a clean feature branch, rebase main. The feature branch may now have, instead of the 10 commits above, eliminated 6 commits that were just things like minor test fixes, typos, etc, and now only has 4 commits total. Instead of 4 conflicting commits, it may now only have 1 or 2, making the rebase simpler as well. And the branch still maintains the traceable history of the development of that feature (assuming good commit messages were used, which is not something the original poster values either).
Comments
I don't agree that folks who rebase multi-commit branches are "doing it wrong". Even if there are multiple stops along the way, that should not be considered a bad thing if it's understood what it is doing.
The way I look at it, lets say I have 10 commits. If I rebase main, commits 3, 4, 7, 10 have "conflicts" with the code that is on main now compared to when I started writing my feature branch and making commits. But, now, I have an opportunity to update code in each of those commits as if I was writing it based on what is now currently on main. If done like that, incrementally, it usually doesn't cascade into conflicts on each commit.
The problem, IMO, comes when at commit 3, the dev says "Oh, I did this like this in commit 10, so let me just put that solution here in commit 3 to resolve this merge conflict". Now, instead of 4 conflicts, you have conflicts on all of the commits between 3 and 10 (because the dev in effect moved the fix from 10 up 7 commits from where it originally was committed). Instead, each conflict resolution should aim to maintain the code as close to the committed code as possible while integrating the code from main. That way also, the feature branch commits still reflect the iterative process that having multiple commits is designed to show.
I don't embrace a FULL squash rebase, but I do embrace cleaning up your branch commits with an interactive cleanup rebase (not on main, just going through the commits for the branch and squashing any minor fixes that belong with the previous commit, etc.) THEN, once you have a clean feature branch, rebase main. The feature branch may now have, instead of the 10 commits above, eliminated 6 commits that were just things like minor test fixes, typos, etc, and now only has 4 commits total. Instead of 4 conflicting commits, it may now only have 1 or 2, making the rebase simpler as well. And the branch still maintains the traceable history of the development of that feature (assuming good commit messages were used, which is not something the original poster values either).