I've used Conventional Commits before but am not a fan of the prefix approach. It often seems arbitrary and makes a git log --oneline less readable. We can accomplish the same with imperative mood english, just as git itself does.
For instance, rather than writing:
feat(template): add a favorite color option
You could instead write:
Add favorite color option for template
You could even remove the scope part as if your project is well organized the changed file should convey this same information.
This is human parseable and machine parseable. We both understand that a subject that starts with "Add" is a feature. You can extend that with regex validation for the other types. The subject can be directly copied into a changelog without stripping prefixes
By "we" I meant machine and human. To ensure complete understanding among peers I agree a simple spec (which would likely be an extension of conventional commit) is in order. Even among the "example" repositories for conventional commit many commits do not follow the spec (i.e. Merge ...). Among other projects such as Deno, I see some commits by maintainers that do not follow the prefix approach as it is more clear without it.
Almost every feat commit I see in the wild starts out as "feat: add" so the prefix is redundant for machines here and a changelog generator should work with or without the prefix.
Even among my monorepos I found scope annoying though I added it habitually it doesn't really add to clarity much. So I'm glad it is optional.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've used Conventional Commits before but am not a fan of the prefix approach. It often seems arbitrary and makes a
git log --onelineless readable. We can accomplish the same with imperative mood english, just as git itself does.For instance, rather than writing:
You could instead write:
You could even remove the scope part as if your project is well organized the changed file should convey this same information.
This is human parseable and machine parseable. We both understand that a subject that starts with "Add" is a feature. You can extend that with regex validation for the other types. The subject can be directly copied into a changelog without stripping prefixes
Examples of git's own messages:
chris.beams.io/posts/git-commit/
Depends. This is not standardised. You may not have the same understanding of your colleague
About the scope, I agree. In small project, it's not necessary. THat's why this field is optional btw.
By "we" I meant machine and human. To ensure complete understanding among peers I agree a simple spec (which would likely be an extension of conventional commit) is in order. Even among the "example" repositories for conventional commit many commits do not follow the spec (i.e. Merge ...). Among other projects such as Deno, I see some commits by maintainers that do not follow the prefix approach as it is more clear without it.
Almost every feat commit I see in the wild starts out as "feat: add" so the prefix is redundant for machines here and a changelog generator should work with or without the prefix.
Even among my monorepos I found scope annoying though I added it habitually it doesn't really add to clarity much. So I'm glad it is optional.