My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something.

To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also felt that this habit is kind of standard - until i had to learn about "conventional commits".

I never got the hype.

▲ jibcage 2 hours ago | parent | next [-]

I personally prefer including issues as git trailers:

    fix thing in foo

    Issue: ABC-123

Git has plenty of builtins for parsing and formatting these trailers, so you can easily create custom git log aliases that let you see them inline and parse them for use with CI.

▲ jadar 3 hours ago | parent | prev | next [-]

Personally, if I am skimming a change log that is already limited in characters, I don’t care about ‘XYZ-999999’ in the main commit message. It’s good to tag as a trailer but I’d much rather see what the commit did than the Jira issue it came from.

	▲	andix an hour ago \| parent \| next [-]
		It's totally fine to put the issue number somewhere at the end of the commit message, and not in line 1. Most tools cross-link them as long as #<issue-id> is mentioned anywhere in the message. It's also useful the other way around, open an issue and see all associated commits.
	▲	willy1234x1 an hour ago \| parent \| prev [-]
		Yeah the ticket value falls off pretty quickly to me. If I pull that up and it's been a closed issue for years and code has been added, rewritten, people moved, and tons of other changes to where the ticket is just a historical artifact and doesn't need priority in the first line of the commit message.

▲ chrishill89 2 hours ago | parent | prev | next [-]

IMO that is only a problem for those who demand that the issue key needs to go first in the subject (which again IMO is bad for readability). I don't see why you can't just stick it somewhere after all the conventional commits junk? Issue keys ought to be something that can be janked out based on a regex like an alphanumeric prefix followed by a number, so things like this "standard" have little need to set aside a space for it.

Personally (without conventional commits) I tend to put them at the end in parentheses if the commit has something to do with that issue. But if there is a stronger relationship like that it fixes the issue, I put a `Fixes` trailer in the message as well.

▲ AlbinoDrought 3 hours ago | parent | prev | next [-]

Interesting, I guess we've been doing it wrong this whole time, as we do `fix(ABC-123): some message here`, which ends up being linked great, renders very nicely into the automated release notes, etc.

▲ beart 3 hours ago | parent | prev | next [-]

It isn't a standard, it is a convention. You can set a standard within your team to include the ticket id in the commit message.

▲ a-dub 3 hours ago | parent | prev | next [-]

yeah this is the actual key. an actually useful title and a stable link to the discussion around the change.

conventional commits are pleasing, but questionable actual utility. the code speaks for itself. the actually useful information is a well chosen title and the context for the change.

▲ 3 hours ago | parent | prev | next [-]

[deleted]

▲ IshKebab 3 hours ago | parent | prev [-]

Why do you even want the issue number in the commit title? I find that super annoying and unfortunately GitHub kind of forces it on you if you use merge queues.

It's fine for it to be in the description.

▲

hebleb 2 hours ago | parent | next [-]

If i'm looking at git history, the ticket number is the most useful piece of info to get more context on the changes for me

▲

alanwreath 2 hours ago | parent | prev [-]

It’s very helpful to know the motivation for the commit and if that motivation was tied to a client contract/feature. Especially in cases where a commit affects multiple files or even just one file so that all commits can be grouped into a feature/contract.

▲

compiler-guy 2 hours ago | parent [-]

COMPANY-1234 in the title doesn't tell the reader all that much about the the feature or motivation. It does tell the client, but I'm not seeing why that is better than having it in the description as a tag, or some other nice way of extracting it.

	▲	willy1234x1 an hour ago \| parent [-]
		Least of all when that ticket is older and so much of the code and the company has changed too. Like sometimes useful historical context sure but worth putting in the first line of a commit? I put it in the body with a link to the ticket or tickets as a footer, if someone wants historical context it's there.