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 an hour 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.