> something like fix, feat, chore, docs, or refactor
'Docs' are also part of the program, they need fixes too, and features need docs. If the docs don't match the features because they're not being updated when the code is, the docs are a lie and waste other developers time.
Also if you were writing a standard: why would you randomly abbreviate 'feature' but not 'refactor'? That sounds like a nitpick but standards require great thought, this is a bit of a smell that there hasn't been much thought into designing 'conventional commits'.
Finally: the name 'Conventional commits' is a land grab (reminds me of when someone made a JS Standard and called it 'StandardJS', ignoring every existing popular standard). From the article, the *actual* convention is 'scope: work"
- Linux
subsystem: description
prefix: description
area: description
package: description
pkg-name: descriptionA changelog is user-facing”
I'd say that ship has probably sailed. Most companies are happy with “Bug Fixes & Performance Improvements”. At least if they're not going to put the effort in, then a generated changelog is better than nothing.
Funny to ask to stop doing something I don't do or never even heard of. I typically only mark database schema migrations or other major things with special prefixes.
This makes neovim plugin manager highlight the change differently which brings attention to it when you update stuff.
So please do use it instead of complaining!
I do like the suggestion of
scope!: ...
if it will be treated the same way with breaking changes reactions.
> fix: prevent foo from bar'ing
The whole idea of conventional commit is:
> fix: [problem]
so the correct conventional commit would be:
> fix: foo bar'ing
which is succinct and perfectly fine.
> fix: prevent racing of requests
Though the example in the actual specification, “fix: array parsing issue when multiple spaces were contained in string”, is more inconclusive (and frankly doesn’t really make sense as a description).
And it’s ugly.
To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also felt that this habit is kind of standard - until i had to learn about "conventional commits".
I never got the hype.
It's fine for it to be in the description.
conventional commits are pleasing, but questionable actual utility. the code speaks for itself. the actually useful information is a well chosen title and the context for the change.
I fully recognise that it doesn't make sense for huge projects like the Linux kernel to do this. But for 99% of projects conventional commits combined with semver vastly improves the release process status quo and makes it easy to automate.
The type of the commit informs the automated workflows how to handle the commit. This is why it comes first.
For example, if you're performing CD, if you only commit a bunch of `fix: ` then only your semantic versioning patch version number is incremented. If you commit a `feat: ` then it's a minor version is bump. `feat! ` is a major version bump.
Even if you're not using CD for releases, semantic commit messages are sometimes used to automate change log generation. Granted, your change logs should not typically include the Git commit messages themselves — those are developer facing, not user facing.
m_m_carvalho•20m ago
Conventional commits are most valuable to me as historical context rather than as a release-management tool.
The larger the project becomes, the more useful that context gets.
radlad•12m ago
d0mine•1m ago
cperciva•12m ago
And the issue isn't whether you can remember what you changed yesterday; this is largely about making sure other developers can quickly identify relevant commits. If you're a solo non-OSS developer, this is entirely relevant to you.