Hey Wolf, it’s a great point that you can use squash effectively. I think the main issue is the “squash & merge every PR” approach, which caused a lot of lost information in one of previous roles. It wasn’t a good solution.
But for day-to-day work, I’d rather just enforce “semantic commit” standards on the team and have everyone write informative commit messages.
If your team is putting in a lot of “fix: reviewer notes” git commits, then you won’t lose any information from merging.
But my commit messages are much more detailed:“fix(`/predictions`): add an additional check for valid query parameters when the page loads based on QA fail and code review for new query parameter PR”
If you agree that it’s worth the developer spending their time to selectively squash their useless commits, then I’d suggest it’s even more worth their time to just write useful commit messages in the first place.
