[mh-cx]

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]

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.

[epmatsw]

I think you’re the first person in this comment section to mention this. Git has a structure for machine-readable structured data. Put it there, not in free text fields for humans.

[codethief]

That's all good and well but the UX sucks. I usually have dozens of commands like

  git commit -m "PROJECT-XXXX Foo the bar to baz the qux"

in my shell history, which means 1) I can easily create follow-up commits under the same ticket number (no having to type the ticket number again), 2) I don't have to keep remembering the ticket number once I created the first commit on the given ticket. I'm sure I could set up an elaborate set of shell scripts and git aliases to auto-insert a ticket number as structured data at the bottom of each of my commits. But good luck convincing the rest of your team to do that.

Also, having the ticket number in the subject line means every git-related tool I use will always display it (even if the rest of the message gets cut off).

[jadar]

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]

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]

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]

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.

[IshKebab]

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]

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

[IshKebab]

Ok... but why does it need to be in the title?

[andrybak]

if IDE supports converting them into clickable links, then scrolling through a log in its Git integration (kinda like `git log --oneline`) will be a convenient list of links to issues. If the commit messages are good, you just skip over the Jira issue/ticket key/ID. If what you want is to see the requirements of a feature or steps to reproduce of a bug or some other context for the ticket, then a clickable link is very convenient. Of course, sometimes it does make sense to include some of that information in the commit message as well.

When working in big teams, it can be very hard to increase the usefulness of commit messages. On the other hand, enforcing inclusion of a Jira issue key in commit messages is easy to implement. Relying on issue tracker descriptions can be a difficult proposition as well. Quality of individual ticket descriptions can be low; depending on how responsibility for maintenance is handled, the bug tracker migrations can sometimes be handled improperly and information can be more easily lost than in a Git log.

[IshKebab]

If the IDE supports that it can easily extract the issue number/link from the commit body too.

[leni536]

It's probably kinda helpful in git blame.

[alanwreath]

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]

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]

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.

[AlbinoDrought]

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]

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]

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.

[c-hendricks]

It's only a convention around commits suggesting to prefix them with certain short words, there's nothing stopping anyone from including issue numbers.

All ours at work do: "feat[component]: DEV-1234: description"