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

81–90 of 99 posts

Re: Conventional Commits: A specification for structured commit messages

#81

Post by antihero »

skrebbel wrote: post #47
_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 t…

It's handy for auto bumping versions, too. If you have "feat" commits you know to bump minor, "fix" to bump patch, and "BREAKING" to bump major.

We use this in our lerna monorepo and it works like a charm as the CI can just bump whatever packages based on the paths and commit messages.

Re: Conventional Commits: A specification for structured commit messages

#82

Post by bregma »

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

"THIS ONE COMMIT MESSAGE DRIVES PROFESSIONAL DEVELOPERS CRAZY!!!"

Re: Conventional Commits: A specification for structured commit messages

#83

Post by cyphar »

iainmerrick wrote: post #69
dmurray wrote: post #60

Earlier quoted context omitted.

Surely the most important part of a commit is the code committed, not the accompanying message .

Yes and no. Both are important. 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.

And commit messages are possibly the best form of documentation when it comes to debugging a problem -- it lets you know exactly what a developer was thinking when the code was written.

Re: Conventional Commits: A specification for structured commit messages

#85

Post by cyphar »

nirvdrum wrote: post #79
hakre wrote: post #51

Earlier quoted context omitted.

the 50 chars is for the subject. the commit message (body) has no character limit (apart from a character limit per line).

Right. But that's the limit I don't get. If I always have to view the expanded set of commit messages to understand anything about the commit, what's the value in a short subject? And why 50 chars? That's even more restrictive than the normal 72/76/80 chars.

It's so that when you print the git-log graph, you don't end up with wrapping of the subject text for deeply-nested trees.

Also, in the kernel generally you reference a different commit in a commit message with the form 'commit ("subject")'. So further restricting it makes sense.

Re: Conventional Commits: A specification for structured commit messages

#87

Post by GordonS »

rinchik wrote: post #6

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)

I quite like the idea of `scope` for large, multi-component projects, so you can tell instantly from the commit message what component has been changed.

Re: Conventional Commits: A specification for structured commit messages

#88

Post by GordonS »

nirvdrum wrote: post #79
hakre wrote: post #51

Earlier quoted context omitted.

the 50 chars is for the subject. the commit message (body) has no character limit (apart from a character limit per line).

Right. But that's the limit I don't get. If I always have to view the expanded set of commit messages to understand anything about the commit, what's the value in a short subject? And why 50 chars? That's even more restrictive than the normal 72/76/80 chars.

I think a limit is helpful to keep the subject line short, but I frequently (like, daily) struggle to fit useful messages into only 50 chars. Personally, I find 72 chars to be the sweet spot.

I wish GitHub or Azure DevOps made this configurable (because I use them) - anyone know if any other hosted git systems have this as a configurable option?

Re: Conventional Commits: A specification for structured commit messages

#89

Post by adrianN »

dchest wrote: post #66
ratherbefuddled wrote: post #63

Earlier quoted context omitted.

Of course not. How else would you do it?

Make a human read the commit history (or tickets) and summarize changes in the language useful for users, not for developers.

I'm sure the human appreciates some help from a script that can parse metadata in the commit messages.

Re: Conventional Commits: A specification for structured commit messages

#90

Post by AndrewHampton »

jackcodes wrote: post #35
AndrewHampton wrote: post #20

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.

Oh, we do. We are generally pretty great at filling in good details in the body. I didn't mention that originally because I didn't think it was noteworthy.

The main problem is very commit titles that end up looking like:

  feat(SomeScope.OtherScope.Class): add support for abc and xyz option
Post reply on HN