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

61–70 of 99 posts

Re: Conventional Commits: A specification for structured commit messages

#61

Post by hakre »

wincent wrote: post #55
skrebbel wrote: post #47

Earlier quoted context omitted.

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…

> Why? The machine-readable part is useful for generating changelogs (eg. broken out by type) or implementing semver (eg. detecting breaking changes).

but isn't it an antipattern to generate change-logs from commit subject lines?

Re: Conventional Commits: A specification for structured commit messages

#62

Post by Karupan »

We’ve found conventional commits useful in our mono repo. Instead of letting the authors deal with versioning (which sometimes breaks dependencies), our build pipeline determines the semver from the commit messages. This has made it easier to deal with releases for around two dozen packages by developers spread across three different countries.

Re: Conventional Commits: A specification for structured commit messages

#63

Post by ratherbefuddled »

hakre wrote: post #61
wincent wrote: post #55

Earlier quoted context omitted.

> Why? The machine-readable part is useful for generating changelogs (eg. broken out by type) or implementing semver (eg. detecting breaking changes).

but isn't it an antipattern to generate change-logs from commit subject lines?

Of course not. How else would you do it?

Re: Conventional Commits: A specification for structured commit messages

#64

Post by ratherbefuddled »

dgellow wrote: post #56
Pfhreak wrote: post #52

Earlier quoted context omitted.

You ever play or work on a game? Changelogs are a big deal over there. Automatically collecting them would be highly valuable.

Do this from your JIRA (or equivalent) tickets then, you already have user oriented descriptions there. you can easily collect all tasks and bug tickets done during a sprint and generate a changelog. Though in practice I would expect someone to cleanup by hand.

How do you link the tickets to the code that was actually built to be sure the changelog is complete and accurate?

It's usual to include the ticket id in the commit or PR so you can pull it from logs at build time and have a canonical list. Then grab the info to include from the ticketing system.

Re: Conventional Commits: A specification for structured commit messages

#65

Post by pantalaimon »

zoomablemind wrote: post #42

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

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

There is `git commit --fixup` and `git rebase -i --autosquash` for that ;)

Re: Conventional Commits: A specification for structured commit messages

#66

Post by dchest »

ratherbefuddled wrote: post #63
hakre wrote: post #61

Earlier quoted context omitted.

but isn't it an antipattern to generate change-logs from commit subject lines?

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.

Re: Conventional Commits: A specification for structured commit messages

#67

Post by cyphar »

ratherbefuddled wrote: post #63
hakre wrote: post #61

Earlier quoted context omitted.

but isn't it an antipattern to generate change-logs from commit subject lines?

Of course not. How else would you do it?

Have a dedicated changelog you maintain[1].

Patch descriptions are for developers, not for users -- aside from the fact they're the wrong granularity (no user cares if it took 20 patches and three PR cycles to implement a feature), they should contain details and justification that are only useful for future debugging or for review purposes (which users also don't care about). And if you have a bugfix for a previously-merged patch that hasn't yet been released, why would you include the bugfix in the changelog?

Yes, with the right format and discipline you could generate reasonable changelogs from your commit logs -- but at that point it's so much easier to just keep a CHANGELOG.md.

[1]: https://keepachangelog.com/en/1.0.0/

Re: Conventional Commits: A specification for structured commit messages

#68

Post by w_t_payne »

I have a system that creates commit messages automatically. The commit messages themselves are YAML so that they can contain various bits of metadata - current task id, timestamps for oldest/newest known builds associated with that task etc...

Re: Conventional Commits: A specification for structured commit messages

#69

Post by iainmerrick »

dmurray wrote: post #60
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…

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.

Re: Conventional Commits: A specification for structured commit messages

#70

Post by arethuza »

JMTQp8lwXL wrote: post #26
munk-a wrote: post #23

Earlier quoted context omitted.

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

[1] has:

"or appends a ! after the type/scope, introduces a breaking API change"

Post reply on HN