instead of 'feat:', why not 'feature:'?
I dislike partial abbreviation because it is confusing; yes doc for document and max for maximum make sense but in this case feat is literally a different word?
Before:
> feat: allow provided config object to extend other configs
After
> Add option for config object to extend other configs
I know this isn't the point of changelogs, but I've been using the verbs from KeepAChangelog to start my commit messages and it's been going well so far.
> Add template preview to status page
> Change textarea to increase height on `:focus`
> Remove deprecated CLI flags
> Fix margin styles causing layout problems
Setting that aside, the conventional commit "standard" (https://xkcd.com/927/) doesn't focus on what I think is the most important aspect of a commit: a good commit subject and message. In fact, prefixing the subject line with certain tags limits the amount of characters you have for writing the message; assuming you want to stick with the usual 50 character limit.
It's useful for automatically determining the next semantic release version by inspecting the commit history alone.
fix: <-- patch
feat: <-- minor
breaking: <-- major
Some fixes will require breaking changes. Fixes can be part of the message with the issue #, etc.
In terms of release management, it makes configuring CI jobs simpler with one less parameter. If you automatically release merges to master, you can use standard-version with conventional commit syntax. On other projects, I've seen people use GitHub PR labels to mark 'major', 'minor', or 'patch' releases (the CI system reads this information when generating releases).
If you feel it's inappropriate for this information to live in your commit history, you'll need to specify it through one of these other options.
Since I don't have a dedicated team for this sort of infrastructure (I maintain my own Jenkins jobs), I find that Conventional Commits get the job done, so I can focus on other things. There could be better ways, but I have more pressing problems than demand my attention, with higher priority than optimizing my CICD configurations.
[0]: https://github.com/conventional-changelog/standard-version
"or appends a ! after the type/scope, introduces a breaking API change"
People do this? I guess it's fine if your commits are <100 lines of code but it seems needlessly concise, to the point of losing information.
Personally, almost all my commits follow email styling: first line tries to be concise, newline, then a list of what changes have been made along with a brief justification. Feels like a bare minimum unless you'd rather tie everything into pr's (which can't be seen from command line). This is why for people unfamiliar with git I refuse to tell them about commit -m because I feel it leads to undocumented history when you need to audit code.
disclaimer: I tend to work on long lived projects (5+ years)
Edit: bonus point that I forgot - by having a detailed commit log that reads like prose, it's easy to explain "everything you guys are working on" to the non technical folks.
The character limit was only referring to the subject line. Under it you can have as many lines of additional context as you wish. That's the normal way; the subject is brief, the message is arbitrarily long.
For what it's worth, the linux kernel limits it to around 70 chars and uses a subsystem prefix, so clearly that can work on large long-lived complex projects.
Your argument against 50 characters in the entire message, including the body, is not one anyone would ever argue for, so you've constructed a complete strawman.
The code is what actually gets run, sure, but good code with bad or misleading documentation can cause trouble later on. Commit messages are documentation.
It's pedantic to me. I'm completly fine with terse incomplete sentences. They are not harder to understand. Plus I work with international teams. Terse is often easier to write and understand for non-native speakers.
As for easier to read thousands of newspaper headlines and magazine article titles provide strong evidence otherwise. Even HN itself is proof it doesn't matter
I like my "Feature" much more than "feat". This is my default commit message that I edit to contain what I want:
<Type>: <Description>
# Type can be:
# - Feature: A new feature
# - Bugfix: A bug fix
# - Docs: Documentation only changes
# - Styling: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
# - Refactor: A code change that neither fixes a bug nor adds a feature
# - Performance: A code change that improves performance
# - Tests: Adding missing tests
# - Chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
From my experience, a few characters less do matter (which is also why I dropped conventional commits and just use "Add blah blah to blah", "Fix typo in user-facing message").
I much prefer encoding structured information like this at the ticket level where history can be more easily corrected and items are expected to be visible for all of time.