>use single emojis for commit messages
The only time that's 100% fine is if you've already legally committed to destroying the codebase by the end of the month.
The only time that's 100% fine is if you've already legally committed to destroying the codebase by the end of the month.
Commit messages are primarily about communicating all of that to others. But if there is no one else to communicate to...
Is it a good idea to have all your commit messages as emojis (or blank) even if you're just working on it yourself? Probably not. Will the codebase be "destroyed" by "the end of the month"? Yeah nah.
I can count on one hand the amount of commit messages I've read that were useful. If I'm trying to understand what the code does I'm more interested in reading the code, even if the commit message is extremely detailed. When the team is small it's even less important because I'm already aware of every change being made.
Just my experience though; would be glad to hear others deriving benefit from commit messages and describing how those messages should be written.
At this point I almost weekly have to review the full context on a pr to make sure my fix won’t break some historical use case that isn’t immediately obvious.
I'd argue tests are much better to guard against accidentally breaking contracts, since they can tell you when that happens, and even why it's important that it doesn't. If that doesn't work, code comments are also good, since they are immediately attached to the relevant code, even if it's refactored and moved elsewhere. "// this looks wrong but " is pretty common in my code.
Warnings in commit messages may be irrelevant, and the deprecation notice may not appear in the same "git annotate".
Especially for projects with any sort of longevity, the commit log is an awfully large haystack to keep such important needles in.