I personally prefer including issues as git trailers:
reply fix thing in foo
Issue: ABC-123
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.
replyIt's totally fine to put the issue number somewhere at the end of the commit message, and not in line 1.
replyMost 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.
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.
replyIMO 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.
replyPersonally (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.
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.
replyIt 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.
replyyeah this is the actual key. an actually useful title and a stable link to the discussion around the change.
replyconventional 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.
deleted
replyWhy 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.
replyIt's fine for it to be in the description.
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
replyIt’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.
replyCOMPANY-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.
replyLeast 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.
reply