It probably depends on the codebase, but I find the best motivation for writing solid commit messages is reading commit messages. Tools like gitlens make this really easy.

Almost daily, I use commit messages and history as part of understanding why a decision was made, why a seemingly obvious alternative wasn’t chosen, etc. seeing the commit title on every line, and hovering to see the full message has become a core editor feature for me.

It’s kind of like testing, the more I do it, the more I want to do it because the value is so consistently reinforced.

There’s nothing like being able to track down exactly why a decision was made 6 years ago in a part of the code base you are struggling to understand written by someone who left before you joined the team.

▲

necrotic_comp 10 hours ago | parent [-]

10,000% this. Attaching JIRA tickets, etc. to the commit helps for searching as well. I've worked with a number of people who do not believe in this and it drives me insane ; I try to enforce it, but there's a lot of messages like "fixed bug" that have zero context or detail associated with them.

I don't understand why so many engineers are like this.

▲

delusional 2 hours ago | parent | next [-]

Attaching JIRA issues makes a ton of sense for features that are described in JIRA. If we're talking about a bug that was found by a developer, unmotivated by a ticket, it would generally make more sense to just describe the bug directly in the commit message. This is of course not true if the JIRA tickets are used for something else downstream, like informing users of fixed bugs, or tracking changes.

The other issue with tagging JIRA tickets is that junior developers will believe that to be enough (you can just read the ticket) and wont understand why they need to describe the change from a technical angle, when it's already described in JIRA.

	▲	zb 2 hours ago \| parent [-]
		Commit messages are immutable. Linking them to a bug ticket gives you a mutable place to record any new information about the bug that you discover in the future. (For example, that it affected more cases than you originally thought, or that the fix caused another bug.) This new information will be discoverable when starting from the original commit (found e.g. by doing a blame on a particular line of source). To fail to do so is a gigantic missed opportunity in my opinion. You never know when you will need it.

▲

tionate 9 hours ago | parent | prev [-]

Attaching ticket numbers has always been enforced by automated checks wherever I have worked, so it is not necessary to “try” to enforce it.

Similarly with AI it is fairly simple to have eg a pre-merge check that validates the commit msg is somewhat useful. This could be implemented for example with GitHub org level checks that must run in a PR.