Argh. I hate that argument.

Yes - "Rewriting history" is a Bad Thing - but o argue that's only on 'main' (or other shared branches). You should (IMHO) absolutely rewrite your local history pre-push for exactly the reasons you state.

If you rewrite main's history and force your changes everybody else is gonna have conflicts. Also - history is important for certain debugging and investigation. Don't be that guy.

Before you push though... rebasing your work to be easily digestible and have a single(ish) focus per commit is so helpful.

• review is easier since concerns aren't mixed
• If a commit needs to be reverted it limits the collateral damage
• history is easier to follow because the commits tell a story

I use a stacked commit tool to help automate rebasing on upstream commits, but you can do it all with git pretty easily.

Anyway. Good on you; Keep the faith; etc etc. :)

At my company we just use a squash policy in gitlab. Every merge request becomes a single commit to the main branch. Super easy to read the commit log because all commits are descriptive instead of a bunch of “fix MR comments” or “fix pipeline errors”.

Another advice: git reset [commit-id] followed with a git commit -a is a quick way to squash all your commits.

Even better, master creating fixup and squash commits and maintain logical commits as you work with git rebase -i --autosquash