[paddez]

{Tests, Code Comments, Documentation} are 3 distinct places to trawl through when quickly going through git blame.

The commit message is one place - and gives the author an opportunity to speak directly with a future developer over the place-in-time-context that this change was made.

[pydry]

Git blame is something you use to ask "what the fuck"? Hence why it's got the tongue in cheek moniker "git blame".

If devs are constantly asking "what the fuck?" all over the code base then that's usually coz tests, code comments, docs and code quality were all badly neglected.

Better commit messages are a band aid over that gaping wound.

[paddez]

You're focusing a bit much on the Developers bit. It's not just Developers who are working through the code-base.

As a lame example - Incident Response/SRE will also be trying to get their heads around changes being made - especially if they're responding to an outage, and trying to figure out what change broke production - and why it was made.

Not everyone will know every bit of the project as intimately as the Dev team - and having a good commit message will help any unfamiliar response team mitigate, or escalate accordingly.

[pydry]

You think incident response would also prefer to go digging around using git blame than just reading your docs?

If you put some effort into your runbooks, not your commit messages, thats where they'll really appreciate good, detailed writing.