I’m just going to continue using Jira ticket numbers.
It baffles me how people think git log reading like a novella is a good idea. It’s not, because a cherrypick or merge can/will/should overwrite whatever clever garbage you put in there with its own message. Are you going to summarize Q4’s battle with scaling in a paragraph on the sprint merge to master? No. No you aren’t.
So, while I’m against commit messages saying “fixed”, obviously, I’m equally against a “conversation” in git.
If you have engineers on your team that are anal about commit messages, ask them to be as anal about features and teach them to git diff.
Ticket numbers are good enough as long as they don't rot (i.e. you never permanently delete tickets). That's just writing the "why" somewhere else instead of in the commit message; the important part is that it's written down somewhere and is discoverable/accessible to future folk (yourself included).
I like putting a minimal description in the message itself too so it's easier to skim the log, though.
It baffles me how people think git log reading like a novella is a good idea. It’s not, because a cherrypick or merge can/will/should overwrite whatever clever garbage you put in there with its own message. Are you going to summarize Q4’s battle with scaling in a paragraph on the sprint merge to master? No. No you aren’t.
So, while I’m against commit messages saying “fixed”, obviously, I’m equally against a “conversation” in git.
If you have engineers on your team that are anal about commit messages, ask them to be as anal about features and teach them to git diff.