Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Conventional Commits: A specification for structured commit messages

conventionalcommits.org

Post reply on HN
Print view View original

1–10 of 99 posts

Re: Conventional Commits: A specification for structured commit messages

#3

Post by house9-2 »

> 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?

Re: Conventional Commits: A specification for structured commit messages

#6

Post by rinchik »

Isn't wording a bit off? "scope" should describe what the commit DOES, not what you are personally DOING, and not what you were intended to DO.

"body", optionally, describes WHY.

Also it feels like more of a convention for a personal project with optional C(I|D) automation prerequisites. In a team there should be a clear and emphasized place for the issue tracking info (ticket number, task id etc etc)

Re: Conventional Commits: A specification for structured commit messages

#7

Post by jhardy54 »

house9-2 wrote: post #3

> 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 on `:focus`

> Remove deprecated CLI flags

> Fix margin styles causing layout problems

Re: Conventional Commits: A specification for structured commit messages

#8

Post by nikolay »

house9-2 wrote: post #3

> 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.

Re: Conventional Commits: A specification for structured commit messages

#9

Post by inlined »

house9-2 wrote: post #3

> 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?

Probably because tools like github truncate large titles

Re: Conventional Commits: A specification for structured commit messages

#10

Post by inlined »

SemVer is generally good practice but I don’t like promotion to religion. For example, during the pre-release of the firebase-functions SDK we shifted SemVer by one: 0.2.1 was a feature addition from 0.2.0 and a breaking change from 0.1.

Similarly there are rare cases where I’ve swept breaking changes under the rug because they were severe bug or security fixes that affected a corner case unlikely to be seen in the wild.

Post reply on HN