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

41–50 of 99 posts

Re: Conventional Commits: A specification for structured commit messages

#41

Post by nirvdrum »

abtinf wrote: post #19

I’ve found the commit message guidelines at https://git-scm.com/book/en/v2/Distributed-Git-Contributing-... to very helpful for clarity. “ The last thing to keep in mind is the commit message. Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a general rule, your messages should start with a single line that’s no more than about 50 characters and that des…

50 chars seems pretty arbitrary to me. I'd rather have a useful commit message. I've seen some pretty contorted messages conveying no real info in order to meet an imaginary character limit.

Re: Conventional Commits: A specification for structured commit messages

#42

Post by zoomablemind »

Commit messages are just that - an additional communication tool. As long as any format helps keep the understanding within a team clear with a minimum of overhead, so be it.

After all the commit message is secondary to the actual code committed.

I'm sure everyone can share an episode when a nicely worded commit had to be followed up with an ugly 'Fix a typo' message.

The most practical convention is the one that's automated to some degree, for example, issue/feature tag auto-linking or some template driven messages. Either way the message should not become an ultimate hoop to jump before the actual commit and one more thing to 'maintain', the code should be the focus.

In my experience, a commit message describing the committed behavior (even when intended) helps tie the code to the overall scope. In case when it's a bugfix, it still must be tied to a correct expected behavior.

So in some sense a commit message could serve as an auxilliary level of unit testing. Of course, I'd rather put an effort to enforce the actual practice of unit testing over structuring the commit messages.

Re: Conventional Commits: A specification for structured commit messages

#43

Post by mgoblu3 »

epage wrote: post #30

At $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…

Similar experience here. On really big teams sure, you can bike shed the format a ton, but they’re all relatively close enough but CC has some good tooling so we just ran with it. Results have been fine, didn’t waste a bunch of time debating it.

Haven’t figured out a good way to integrate co-authors easily with it though.

Re: Conventional Commits: A specification for structured commit messages

#44

Post by nikolay »

mdtusz wrote: post #40
nikolay wrote: post #24

Earlier quoted context omitted.

Nice! "Styling" could be ambiguous though. I personally use "Formatting" instead.

I typically go with "Linting". "Formatting" could mean something different in some contexts.

That's even a better choice. Thank you!

Re: Conventional Commits: A specification for structured commit messages

#45

Post by _glsb »

Imagine the following future:

“Have you linted and unit tested your commit message?”

“Junior Developer wanted. 10 years of Conventional Commits experience required.”

“Download Conventionalizer! Now you can write Conventional Commits in plain English, having all the syntax automatically generated! (node, erlang OTP and Jerry’s pre-alpha TensorFlow binding library required. Windows support coming soon.)”

Something tells me the authors are hard at work solving a problem nobody needs solving.

Re: Conventional Commits: A specification for structured commit messages

#46

Post by TheDong »

eyegor wrote: post #28
YorickPeterse wrote: post #14

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…

> 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 ref…

You're arguing against a strawman because you misunderstood the parent comment.

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.

Re: Conventional Commits: A specification for structured commit messages

#47

Post by skrebbel »

_glsb wrote: post #45

Imagine the following future: “Have you linted and unit tested your commit message?” “Junior Developer wanted. 10 years of Conventional Commits experience required.” “Download Conventionalizer! Now you can write Conventional Commits in plain English, having all the syntax automatically generated! (node, erlang OTP and Jerry’s pre-alpha TensorFlow binding library required. Windows support coming soon.)” Something tell…

On come on, this entire "spec" can be summarized in two sentences. It can be validated with a 13 character regex.

I share some of your sentiment though: I feel like the biggest reason to enforce a style like this is not for "machine readable commit messages" (I mean, why?), but to encourage people to split refactors and features in separate commits. This makes it easier to understand what's going on later.

I think this site should've begun with that, and left the spec as a footnote.

Re: Conventional Commits: A specification for structured commit messages

#50

Post by Svoka »

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 only saves you like 3 symbols. Made a pull request fixing it https://github.com/conventional-commits/conventionalcommits....
Post reply on HN