31–40 of 99 posts
This actually had me laughing quite a bit. Because of my love for dad jokes, here are some less conventional commits:
"fete" : adding holiday support
"braking change" : a change of pace
"nix" : removing a featute
"suffix" : adding a nice to have
> 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?
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 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.
lost me at “feat”
We've been following conventional commits for our front end code for the last year or so at my work. In other repositories, we've loosely followed the keep a change log conventions. I find conventional commits great when your repository will produce a package to be consumed by others. For example, conventional commits for our shared JS code helps us produce great change logs and helps us easily follow semver for the…
I see this in nearly every company I go to - everyone rushing to skip over adding anything useful to the permanent log by using git commit -m rather than a plain got commit.
We've been following conventional commits for our front end code for the last year or so at my work. In other repositories, we've loosely followed the keep a change log conventions. I find conventional commits great when your repository will produce a package to be consumed by others. For example, conventional commits for our shared JS code helps us produce great change logs and helps us easily follow semver for the…
Why don’t they put the additional information in the body of the commit? I see this in nearly every company I go to - everyone rushing to skip over adding anything useful to the permanent log by using git commit -m rather than a plain got commit.
> 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?
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…
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.
Earlier 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
Some fixes will require breaking changes. Fixes can be part of the message with the issue #, etc.
Earlier 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…
Why? Why is there such a strong desire for full sentences? 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.
Earlier quoted context omitted.
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.