Commit messages don't matter as much in pull request workflows.
Whether or not this is ideal, the modern developer workflow centers around the pull request. This means that commits aren't as useful as they used to be. Why?
- Lack of patch-ability, CI/CD. More often than not, commits as patches don't stand up to scrutiny – they aren't individually patchable to the main branch or might not pass all integration tests. CI/CD is often triggered at the pull request level, not individual commits off the main branch.
- Squashed anyways. While I admire authors who painstakingly break commits up into buildable, reviewable units, this is often not a good use of the author's (or reviewer's) time. More often than not, this work is only for the review stage, as commit granularity is lost when they are squashed, rebased, or merged committed. If the goal is reviewability, why not split it into multiple pull requests?
- The full context isn't in VCS. The full context is often found in the pull request description, reviews, and issues. Context hidden away in commit messages doesn't tell the entire story. While some developers might think it's purer to have a self-contained repository where all decisions are recorded in commit logs, I've rarely seen this be the case.
- Commit messages aren't reliable sources of metadata. Commit messages are not a good place to put context information about what has changed. Even granular commits will often affect more than one file or folder. What about a bug fix that found its way into a
feat:commit? It's better to reference the ground truth –git difforgit blame.