mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2026-03-22 12:44:37 -05:00
feat is contracted, most other commonly used tags are full words.
#190
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/conventionalcommits.org#190
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mikemaccana on GitHub (Sep 8, 2023).
In the most common use of this spec the terms are almost always full words, with two exceptions
featandperfSuggest retiring
featandperfand replace withfeatureandperformancefor consistency.perfis outside the scope of this repo though.Rationale
Searching for
featurein commit messages using this spec won't return commits using the termfeature, which is a reasonable commit message to add a feature.@purohitdheeraj commented on GitHub (Oct 6, 2023):
Very thoughtful , even in verbal communication while pair programming or while guiding juniors
i have observed that contracted words like feat and perf can create confusion
so it's great idea to make it complete
if needed i can work on this issue @mikemaccana
thank you , have a nice day
@Jakub-PMX commented on GitHub (Jan 24, 2024):
The dictionary explains what
featis:So it can be confused with
feature. Please change thatfeatinto afeature🙏@DoppioJP commented on GitHub (Jan 26, 2024):
@javier-godoy commented on GitHub (Jan 26, 2024):
The proposed change adds 3 characters to the commit header (thereby substracting them from the commit subject, if one wants to keep it below 72 characters). Those 3 characters are precious, particularly for languages other than English where it's already difficult to fit such limit. I would rather keep
feat:@Jakub-PMX commented on GitHub (Jan 29, 2024):
In that case go with:
fe:for the featurefi:for the fixetc.
Or, remove the prefix completely from the commit, knowing that the branch the commit is in, already has that prefix anyway, so why repeat yourself? And then, on the squash commit - put that prefix in (which will automatically be added anyway from the PR title) and there will still be a description in the separate lines of the commit message.
Regardless of your or my preferences, the
featmeans something different than thefeature- those are 2 different words.@Jakub-PMX commented on GitHub (Jan 31, 2024):
@javier-godoy How about
refactor? It is 8 characters, whilefeatureis 7. 🤔@javier-godoy commented on GitHub (Jan 31, 2024):
@Jakub-PMX
refactoris not defined in the conventional commits specification (onlyfixandfeatare).@DoppioJP commented on GitHub (Feb 18, 2024):
Claro 👍
@NikosAlexandris commented on GitHub (Apr 4, 2024):
Precious characters, indeed. Precious language, nonetheless. I'd vote for full words (i.e. "feature"). I didn't know that "feat" is a word, though.
@DoppioJP commented on GitHub (Jan 23, 2026):
This comes back like a bad nightmare. It is beyond me why natively English speaking people involved in this project went with
featwhilefeaturehas been used for many years before. I get that some want to save 3 "precious" characters 🤦♂️ , people have weird preferences. Maybe my preference to usefeatureis also weird 🤷♂️ .Anyway, seeing that this CC (sorry, using the word "conventional" here don't make no sense to me) is widely adopted and tangled into many tools, which then are forced on some people at work, I am starting a new quest:
Adding
featuretype/prefix as a legal citizen at CC realm, alongside existingfeatI realise that getting this approved here (which at this stage I am not sure why I believe is possible), is just a start. Then I will go through all the tools, which I came across and will submit PRs there, which will allow to include
featurethere as well.🤞 🤞 🤞 🤞 🤞 🤞 🤞 🤞 🤞 🤞 🤞 🤞