Modify format of conventional commits

[topolanekmartin]

Hello,

I would like to change format of conventional commits in order to prepend task ID (in my case it would be Jira task id) to commit. You can see below new format:

<[XXX-1234]> <type>[optional scope]: <description>

Is it possible to modify it somehow? I mean some local file in which I would define new format for custom project.

Thanks in advance for answer.

[xlttj]

Although it might be convenient to have a reference to some kind of issue number in the first line, there are some drawbacks. The first line gets even longer, so more essential information might not be displayed in commit lists. Think 50/72 characters.

A subject line beginning with

JIRA-1253 refactor(service): 

takes more than half of the space and leaves 21 characters for describing the commit itself.

The recommended place for these references is the footer. That gives them more room, you can still search for references in the log and you can even mention multiple references.

refactor(service): 31 characters for description

Long description […]

JIRA-1253 - Refactor the service to increase whatever

But of course you can deviate from (de-facto) standards in your own projects and write your commit messages as it fits you best. Just my 2 ct.

[Conaclos]

I could rather favor something like: <type>[scope][!]: <desc> [ticket-ref]

refactor(service): description (JIRA-1253)

This format (ticket in parens and after the description) seems widely used.

[dsbert]

We do the same, ~and unfortunately it still breaks the spec (first line should be all lower-case).~

Edit: my bad, that's not actually in the spec. Not sure where I got that from.

[pip25]

The absence of task/ticket identifiers in the first commit line is the number one reason why we cannot adopt this spec, and is honestly a surprising oversight. In many corporate environments, especially where the large number of developers makes the quality of commit messages rather uneven, a ticket ID is in fact the most essential information in the commit message. Relegating it to a footer entry, as the current examples show, hides a crucial detail from many commit history views, including Github's.

I think a place already exists in the current format that matches the role of a ticket ID well: the scope identifier. Instead of allowing only a single noun, I would suggest relaxing the requirements here to allow commit comments such as this:

fix(JIRA-1234): Fixed NullPointerException in SomeService

Or this:

refactor(#321): Removed unnecessary iterators

We could still disallow spaces in the scope field to discourage people from writing something overly long.

[bcoe]

People can update the message to have a suffix which represents a ticket #, like:

refactor(service): description (JIRA-1253)

As @Conaclos suggests.

Alternatively, we use git trailers to reference the originating ticket:

test: use fully qualified request type name in tests

Origin-RevId: 132334

With regards to @pip25's suggestion, I think this is reasonable for someone's internal use 👍, I could imagine us documenting this in the help section, as a potential option for people.

---

@topolanekmartin you can create your own custom parser you use internally at your company, that handles commits in the format you've suggested.

This repository describes a specification, and is not a tool for parsing commits.

For the specification itself, we are not going to introduce an additional prefix like <[XXX-1234]> ahead of the type, as I I think this is sufficiently supported by conventions like git trailers, or adding a suffix to the description.