StealthyCoder

When I start this conversation, I usually get the same reactions as I give myself. Who cares about clean git history?

It matters

It actually matters. So most of us do not use git to the fullest extend possible. We create branches, make commits, or one giant one. Then make a PR and merge that into whatever main or develop branch you have. I am, or should say was, one of those devs as well.

I came to realize it actually matters that you rebase instead of just always squash merge because it keeps everything in check. It also allows for some powerful git bisect where you can easily track what happened to a piece of code.

We all use git blame on a line of code when we want to see who wrote this and ask them to explain what this piece of code does. Then it almost always turns out you yourself wrote the code back then and are now left wondering what was going through your mind at the time.

Good habit

Start by making it a habit to write conventional commit messages. At least try to. Then try to go over your commits themselves. Split everything as much as you can into nice grouped changes. Everything related to this particular bug, and then some extra commits for the cleanups along the way. Then at the end you can git rebase -i HEAD~<nr of commits> to make it all nice and clean.

Just begin slowly and then after a while you will realize it is a good thing to think about the actual commit you are making. What is it doing? Is it clear and understandable, so it can be reviewed properly?

Also it makes you double check your code way more often if CI builds fail because of a linter issue. Since you know you have to do more steps than just run the linter and git commit -am "Fix CI". You have to git commit, then git rebase -i followed by a git push --force.

Conclusion

Just try it, and see if it takes away anxiety and generates some calm.