Bingo! This strategy has worked well for my org (75+ engineers) for years. If an engineer makes non-related bug fixes in the same branch we require them to reve

Bingo! This strategy has worked well for my org (75+ engineers) for years. If an engineer makes non-related bug fixes in the same branch we require them to revert the change and make a new branch. We also have each GitHub repo configured so the "Squash and Merge" option is the ONLY option available when merging a PR. I don't care one lick what someone's branch history looks like. If they want to commit every day, or every hour, or after every keystroke - I don't care. All I know is that once the PR is merged, it's all going to be squashed into a logical unit so the `main` commit history will look just fine.