Comment by Vampiero
1 day ago
It seems painfully obvious to me that local and remote commits serve different purposes. Local commits are a way to create checkpoints when everything compiles and works and you can move on to the next step. That way you can stash your changes and go back to a working state when you screw things up. Then, before you push those changes, you reset them and split them into proper commits. That way the history is all nice and clean on the remote and it's not just a bunch of "wip"s.
Or you can just squash-merge your PRs and reap both benefits.
I have no pride. I push my dumb commits that chronical my weird journey full of sub-junior mistakes to get to the final state.
I think people would generally have an easier time with git if they didn't try to fix their commit histories and instead just let their past mistakes be known. If you make a bad commit in git the best solution is to follow it up with a good one that fixes the problem. Squash commits on PRs help too.
Even better, `git merge --no-ff` your PRs and use `git log --first-parent` for the simplified "as-if-it-was-squashed" history.