I don’t think this is so much to make your commit messages better, as it is to make sure that all of them can be automatically processed into changelog and semver updates.
Conventional Commits: A specification for structured commit messages
21–30 of 99 posts
Re: Conventional Commits: A specification for structured commit messages
#22> feat: a commit of the type feat introduces a new feature to the codebase 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?
I also dislike unnecessary abbreviations. "Feat" saves you just 3 characters, but earns you ugliness and confusion.
It seems like it was made by someone who accidentally spilt coffee on their keyboard which made their 'U' key sticky.
I like my "Feature" much more than "feat". This is my default commit message that I edit to contain what I want:
:
# 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
Re: Conventional Commits: A specification for structured commit messages
#23Earlier quoted context omitted.
I agree that full sentences (e.g. like Email subjects or blog post titles) are better. Tagging commits with feature/bug/etc is not particularly useful, as more often than not the line between feature, bug, etc is blurry. At times it can also be unclear what tag to use, leading to arbitrary choices. For example: is a performance improvement a feature, or a bug fix? The tags also add no value when reading commit messag…
> feature/bug/etc is not particularly useful It's useful for automatically determining the next semantic release version by inspecting the commit history alone. fix: feat: breaking: <-- major
That seems inaccurate, it looks more like fix: feat: are both potentially patch level while fix!: feat!: breaking change: and breaking change!: indicate major changes... possibly? Ouf I think the commit is just absolutely the wrong level to encode this at - I much prefer ticket level encoding of this information.
Re: Conventional Commits: A specification for structured commit messages
#24Earlier quoted context omitted.
I also dislike unnecessary abbreviations. "Feat" saves you just 3 characters, but earns you ugliness and confusion.
It seems like it was made by someone who accidentally spilt coffee on their keyboard which made their 'U' key sticky. I like my "Feature" much more than "feat". This is my default commit message that I edit to contain what I want: : # 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, formatti…
Nice! "Styling" could be ambiguous though. I personally use "Formatting" instead.
Re: Conventional Commits: A specification for structured commit messages
#25> feat: a commit of the type feat introduces a new feature to the codebase 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?
`feat` is only a saver over `feature` if you're making a descriptor that was optional into something required - I admit I've never worked with a public commit history but for our internal projects commit messages are expected to give some justification or explanation of the necessity of the change without any formatting specifically enforced (though we require branches to contain at least one commit that pulls in the related issue ticket #).
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.
Re: Conventional Commits: A specification for structured commit messages
#26Earlier quoted context omitted.
> feature/bug/etc is not particularly useful It's useful for automatically determining the next semantic release version by inspecting the commit history alone. fix: feat: breaking: <-- major
That seems inaccurate, it looks more like fix: feat: are both potentially patch level while fix!: feat!: breaking change: and breaking change!: indicate major changes... possibly? Ouf I think the commit is just absolutely the wrong level to encode this at - I much prefer ticket level encoding of this information.
I was explaining how standard-version [0] works. Conventional Commits homepage doesn't mention anything about the '!' syntax. [1] I'm unsure if you're suggesting that's how you think it should work, or how it actually works. I haven't ever tried using the '!' syntax, so I can't say for certain.
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
Re: Conventional Commits: A specification for structured commit messages
#27For use cases where this level of rigour is desired, it would be nice to have real separate metadata vs. convention. Doing this by convention is unreliable.
Re: Conventional Commits: A specification for structured commit messages
#28Earlier quoted context omitted.
And while we're at it, why don't we just use full sentences? 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…
I agree that full sentences (e.g. like Email subjects or blog post titles) are better. Tagging commits with feature/bug/etc is not particularly useful, as more often than not the line between feature, bug, etc is blurry. At times it can also be unclear what tag to use, leading to arbitrary choices. For example: is a performance improvement a feature, or a bug fix? The tags also add no value when reading commit messag…
> the usual 50 character limit.
People do this? I guess it's fine if your commits are 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.
Re: Conventional Commits: A specification for structured commit messages
#29I'm sticking to the GNU ChangeLog format, thanks. https://www.gnu.org/prep/standards/html_node/Change-Logs.htm... This widely used format gives details about what is being done to each function. This was designed to be used in a ChangeLog file, so it has to be adopted for repository use. We don't have to record the date and name, since that is in the commit meta-data. WE write a commit title, and then the ChangeLog e…
Personally, I feel like this style puts the focus on what rather than the why. I also dislike that it seems to be centered on multiple changes in one commit.
Re: Conventional Commits: A specification for structured commit messages
#30At $DAYJOB, we organically switched from not having any formal style to having an internal formal style. People seemed to want the benefits of tooling integration and clearer communication.
Right now, we are switching SCM's and are looking at adopting Conventional to replace our internal style. I've already started using Conventional and have really appreciated it. It makes it fast and succinct (remember, line length "requirements" in git) to get the information you need even in one-line logs. Also, it makes CHANGELOG maintenance easier, whether using an automated tool or doing it by-hand.
Not happy with the other ones, I've created my own commit style validation tool, committed [0] and have deployed it on my open source projects. Like code style enforcement in CI, I like delegating this to a tool since it makes the requirement very clear for contributors.
The one thing I'm disappointed with with Conventional is that they did not follow git conventions for multi-line trailers.