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

[–] thesmokingman@programming.dev 5 points 8 months ago

The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.