add full list of potential values for "type", with descriptions #106

New Issue

GiteaMirror · 2026-02-17T11:46:22-06:00

GiteaMirror commented

2026-02-17 11:46:22 -06:00

Originally created by @bnb on GitHub (Jul 13, 2020).

I consistently want to use conventional commits. I generally partially use it rather than fully using it though, using a subset of the types. I can't consistently or easily find all the potential types, so I use the ones I know that are descriptive.

It would be wonderful to get a full list of the types, what they mean, and when they should be used.

Originally created by @bnb on GitHub (Jul 13, 2020). I consistently want to use conventional commits. I generally partially use it rather than fully using it though, using a subset of the types. I can't consistently or easily find all the potential types, so I use the ones I know that are descriptive. It would be wonderful to get a full list of the types, what they mean, and when they should be used.

GiteaMirror commented

2026-02-17 11:46:24 -06:00

@damianopetrungaro commented on GitHub (Jul 16, 2020):

This is a good one tho.
I think this https://github.com/streamich/git-cz#custom-config may be a good starting point.

Do you have any other type you use @bnb ?

@damianopetrungaro commented on GitHub (Jul 16, 2020): This is a good one tho. I think this https://github.com/streamich/git-cz#custom-config may be a good starting point. Do you have any other type you use @bnb ?

GiteaMirror commented

2026-02-17 11:46:24 -06:00

@wesleytodd commented on GitHub (Sep 30, 2020):

So I think the spec is intentionally limited here. It says:

Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc.,

So the only officially "spec'd" types are feat and fix. All additional ones are etc, and up to you. I am a fan of pulling some of the other useful ones from that list up into the spec, but I think we should be careful of how far we go in this area as many could be controversial and ambiguous in many situations.

@wesleytodd commented on GitHub (Sep 30, 2020): So I think the spec is intentionally limited here. It says: > Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., So the only officially "spec'd" types are `feat` and `fix`. All additional ones are `etc`, and up to you. I am a fan of pulling some of the other useful ones from that list up into the spec, but I think we should be careful of how far we go in this area as many could be controversial and ambiguous in many situations.

GiteaMirror commented

2026-02-17 11:46:25 -06:00

@tunnckoCore commented on GitHub (Oct 3, 2020):

I don't see why such things should be in the spec at all when we have awesome tooling like commitlint, git-cz, and a ton of other useful and cool helpers. The most important reason they exist is that the spec is so simple.

@tunnckoCore commented on GitHub (Oct 3, 2020): I don't see why such things should be in the spec at all when we have awesome tooling like `commitlint`, `git-cz`, and a ton of other useful and cool helpers. The most important reason they exist is that the spec is so simple.

GiteaMirror commented

2026-02-17 11:46:26 -06:00

@bnb commented on GitHub (Oct 12, 2020):

for reference, these are the ones I've generally seen:

docs
ci
test
build
chore

@bnb commented on GitHub (Oct 12, 2020): for reference, these are the ones I've generally seen: - docs - ci - test - build - chore

GiteaMirror commented

2026-02-17 11:46:27 -06:00

@majew7 commented on GitHub (Feb 1, 2022):

I feel the same as @bnb, I too can't consistently or easily find all the potential types from the Quick Summary. I expected it to quickly answer the question "What type prefix should I use for my commit?", which is what I often ask right before right a commit message, and thus an enumeration of the types with descriptions would be helpful.

@wesleytodd wrote:

So the only officially "spec'd" types are feat and fix.

So it appears this Conventional Commit Specification is lighter than I'd prefer, and thus cannot answer my question.

The tension for me is I want this specification to to round out the other types (e.g. docs:, ci:, test:). I want a single place to go to answer this question near the specification. Tools like commitlint are cool, and not a spec however. They too don't answer my question quickly.

@majew7 commented on GitHub (Feb 1, 2022): I feel the same as @bnb, I too can't consistently or easily find all the potential types from the [Quick Summary](https://www.conventionalcommits.org/en/v1.0.0/#summary). I expected it to quickly answer the question _**"What type prefix should I use for my commit?"**_, which is what I often ask right before right a commit message, and thus an enumeration of the types with descriptions would be helpful. @wesleytodd wrote: > So the only officially "spec'd" types are feat and fix. So it appears this Conventional Commit Specification is lighter than I'd prefer, and thus cannot answer my question. The tension for me is I _want_ this specification to to round out the other types (e.g. `docs:`, `ci:`, `test:`). I want a single place to go to answer this question near the specification. Tools like `commitlint ` are cool, and not a spec however. They too don't answer my question quickly.

GiteaMirror commented

2026-02-17 11:46:28 -06:00

@javier-godoy commented on GitHub (Feb 7, 2022):

@wesleytodd wrote:

So the only officially "spec'd" types are feat and fix. All additional ones are etc, and up to you. I am a fan of pulling some of the other useful ones from that list up into the spec, but I think we should be careful of how far we go in this area as many could be controversial and ambiguous in many situations [emphasis mine]

IMHO it's a good thing that the spec itself isn't too strict on which types are allowed. After all, the spec is a lightweight convention. One of the FAQ answers "recommend using SemVer to release your own extensions to this specification (and encourage you to make these extensions!)".

We followed that approach with some colleagues and agreed on definitions for each of those additional types (here) that make sense for us (and hopefully for somebody else).

@javier-godoy commented on GitHub (Feb 7, 2022): @wesleytodd wrote: > So the only officially "spec'd" types are `feat` and `fix`. All additional ones are `etc`, and up to you. I am a fan of pulling some of the other useful ones from that list up into the spec, but I think we should be careful of how far we go in this area as **many could be controversial and ambiguous in many situations** [emphasis mine] IMHO it's a good thing that the spec itself isn't too strict on which types are allowed. After all, the spec is a _lightweight convention_. One of the FAQ answers "recommend using SemVer to release your own extensions to this specification (and encourage you to make these extensions!)". We followed that approach with some colleagues and agreed on definitions for each of those additional types ([here](https://github.com/FlowingCode/DevelopmentConventions/blob/main/conventional-commits.md#1-type)) that make sense for us (and hopefully for somebody else).

GiteaMirror commented

2026-02-17 11:46:29 -06:00

@0x404 commented on GitHub (Oct 2, 2024):

Hi there,

We are very interested in the Conventional Commits Specification and greatly appreciate the amazing work you have done. We conducted a study and found that conventional commits are becoming increasingly popular among top open-source projects. Specifically, there is a stable uptrend in the adoption of conventional commits, with some projects mandating their use. By 2023, in repositories that do not require conventional commits, we found nearly 10% of commits were in line with the Conventional Commit format, indicating their popularity among developers.

During this process, we noticed that some commits, despite being conventional, clearly misused the commit message format, for example: feat: remove unnecessary lines from test file. This spurred our curiosity about the challenges developers face when categorizing commits using the conventional commits format. Therefore, we analyzed all the issues in this project, as well as the top 100 questions on Stack Overflow related to conventional commits. Our analysis identified four categories of challenges developers face, with the most common (around 57.7%) being confusion over which type to use. In the current CCS definition, categories other than 'feat' and 'fix' lack clear definitions, leading developers to rely on the categorizations used by Angular and other projects, which often overlap and lack clarity. For instance, in Angular's definition, 'refactor' is defined as "A code change that neither fixes a bug nor adds a feature," which could ambiguously include 'style', 'perf', 'test', among others.

To move this discussion forward, we have proposed a clearer and less overlapping list of definitions based on our literature review and the documentation in repositories currently using conventional commits. Based on this, we have drafted an academic paper (you can find more detailed information about the above here), which has undergone peer review and been accepted by ICSE 2025, a premier software engineering conference.

We thought our proposed definitions might help advance this issue. We would love to hear your thoughts on this. If you are interested or have any questions, please let me know. cc @damianopetrungaro

@0x404 commented on GitHub (Oct 2, 2024): Hi there, We are very interested in the Conventional Commits Specification and greatly appreciate the amazing work you have done. We conducted a study and found that conventional commits are becoming increasingly popular among top open-source projects. Specifically, there is a stable uptrend in the adoption of conventional commits, with some projects mandating their use. By 2023, in repositories that do not require conventional commits, we found nearly 10% of commits were in line with the Conventional Commit format, indicating their popularity among developers. During this process, we noticed that some commits, despite being conventional, clearly misused the commit message format, for example: `feat: remove unnecessary lines from test file`. This spurred our curiosity about the challenges developers face when categorizing commits using the conventional commits format. Therefore, we analyzed all the issues in this project, as well as the top 100 questions on Stack Overflow related to conventional commits. Our analysis identified four categories of challenges developers face, with the most common (around 57.7%) being confusion over which type to use. In the current CCS definition, categories other than 'feat' and 'fix' lack clear definitions, leading developers to rely on the categorizations used by Angular and other projects, which often overlap and lack clarity. For instance, in Angular's definition, 'refactor' is defined as "A code change that neither fixes a bug nor adds a feature," which could ambiguously include 'style', 'perf', 'test', among others. To move this discussion forward, we have proposed a clearer and less overlapping list of definitions based on our literature review and the documentation in repositories currently using conventional commits. Based on this, we have drafted an academic paper (you can find more detailed information about the above [here](https://github.com/0x404/conventional-commit-classification/blob/main/paper.pdf)), which has undergone peer review and been accepted by [ICSE 2025](https://conf.researchr.org/home/icse-2025), a premier software engineering conference. We thought our proposed definitions might help advance this issue. We would love to hear your thoughts on this. If you are interested or have any questions, please let me know. cc @damianopetrungaro

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#106