Modify format of conventional commits #150

New Issue

GiteaMirror · 2026-02-17T11:49:50-06:00

GiteaMirror commented

2026-02-17 11:49:50 -06:00

Originally created by @topolanekmartin on GitHub (Jun 14, 2022).

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.

Originally created by @topolanekmartin on GitHub (Jun 14, 2022). 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.

GiteaMirror closed this issue

2026-02-17 11:49:50 -06:00

GiteaMirror commented

2026-02-17 11:49:51 -06:00

@xlttj commented on GitHub (Jul 6, 2022):

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.

@xlttj commented on GitHub (Jul 6, 2022): 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.

GiteaMirror commented

2026-02-17 11:49:52 -06:00

@Conaclos commented on GitHub (Aug 3, 2022):

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.

@Conaclos commented on GitHub (Aug 3, 2022): 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.

GiteaMirror commented

2026-02-17 11:49:53 -06:00

@dsbert commented on GitHub (Sep 7, 2022):

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.

@dsbert commented on GitHub (Sep 7, 2022): 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.

GiteaMirror commented

2026-02-17 11:49:54 -06:00

@pip25 commented on GitHub (Oct 20, 2022):

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.

@pip25 commented on GitHub (Oct 20, 2022): 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.

GiteaMirror commented

2026-02-17 11:49:55 -06:00

@bcoe commented on GitHub (Nov 3, 2022):

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.

@bcoe commented on GitHub (Nov 3, 2022): 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`.

GiteaMirror referenced this issue

2026-02-17 11:58:52 -06:00

[PR #150] [MERGED] translation overlook and broken markdown fixed #319

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#150