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

91–99 of 99 posts

Re: Conventional Commits: A specification for structured commit messages

#91

Post by _qwfv »

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.

Ha! Maybe I just worked in a less organized game studio, but the only reliable record was the commit log.

Except when people would literally just mash their keyboard like this:

Commit 1234: iuadiuasdbuidawbiywbuqbqbdfpbdpiube

Re: Conventional Commits: A specification for structured commit messages

#92

Post by leerob »

Conventional commits pair nicely with a Lerna monorepo when deploying multiple JS packages at once. Auto-generated changelogs and automatic semver for packages. It's worked well for us over the past year.

https://github.com/lerna/lerna/blob/master/commands/version/...

Re: Conventional Commits: A specification for structured commit messages

#93

Post by wincent »

cyphar wrote: post #80
wincent wrote: post #76

Earlier quoted context omitted.

That all depends on what you do with the meta-data in the commits. For example, at my work, we analyze the history at the level of merges, not commits, and that works pretty well for us.

Merge information is incredibly useful to developers (even if only to provide a smart "git bisect"). But would you generate a user-visible changelog from your merges? I personally wouldn't, and that's the point GP was making.

> But would you generate a user-visible changelog from your merges?

We can, and do. Knowing that the merges are going to wind up as items in the changelog leads us to size and structure them accordingly, or at least make a best effort to. The end result is a changelog where most PRs are somehow "noteworthy" and the ones that aren't (usually "chore" type in Conventional Commits lingo) can all be grouped together down the tail end.

The point isn't to produce a perfect result, but one that is "good enough". With this system, the friction to produce a new release is so low, and we have so many projects, that we can easily push out a steady stream of releases at very low cost with this approach. And following the pattern across all the projects has been great for consistency, compared to the relative chaos in patterns and procedures that we had before.

Re: Conventional Commits: A specification for structured commit messages

#94

Post by wincent »

notmyfuture wrote: post #27

For use cases where this level of rigour is desired, it would be nice to have real separate metadata vs. convention. Doing this by convention is unreliable.

You can get a basic level of enforcement for free by turning on the "Semantic Pull Requests" bot that will let you know when you forget the type (or use an invalid one):

https://github.com/probot/semantic-pull-requests

It obviously won't catch your mistake if you forget to mark a breaking change as breaking, but it's a start.

Re: Conventional Commits: A specification for structured commit messages

#95

Post by nirvdrum »

cyphar wrote: post #85
nirvdrum wrote: post #79

Earlier quoted context omitted.

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.

Okay. But I contend that makes the whole log worth less because the short commit messages are often devoid of useful info. Granted, I don't have an email-based patch workflow; I look at logs on both GitHub and pulled in from the CLI. On GitHub, things are even worse because I have to constantly expand commits to see what actually changed.

In any event, I think teams should be free to adopt the workflow that works best for them without tools getting in the way. GitHub wrapping commit messages at 70 chars, even though I have more than plenty enough horizontal real estate, isn't helping anyone.

Re: Conventional Commits: A specification for structured commit messages

#96

Post by nirvdrum »

GordonS wrote: post #88
nirvdrum wrote: post #79

Earlier quoted context omitted.

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?

I'm in favor of a team being able to set a limit if they'd like and tools adapting. Personally, I'd rather a 90 char commit message that conveys useful info than a contorted message intended to fit in 1/3 the size of an SMS message.

Re: Conventional Commits: A specification for structured commit messages

#97

Post by epage »

mgoblu3 wrote: post #43
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.

Wouldn't Co-Authors just be a footer/trailer?

Re: Conventional Commits: A specification for structured commit messages

#98

Post by ratherbefuddled »

cyphar wrote: post #67
ratherbefuddled wrote: post #63

Earlier quoted context omitted.

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

In my experience its unlikely this will be complete or accurate on any project maintained by a team of more than a couple of people.

Common practice for a long time has been to include a ticket id in the commit and then use a script to pull all the ticket ids from the commits since the last release and pull the (user facing) release note info from ticketing system.

Of course you don't want commit messages going to users but you don't want to rely on handcrafted lists either. Particularly when a release as far as a customer is concerned is infrequent and contains changes from many repos.

Re: Conventional Commits: A specification for structured commit messages

#99

Post by greggman2 »

greggman2 wrote: post #37
jhardy54 wrote: post #7

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.

OCD seems prevalent in programmers. For me full sentence comment / commit message requirements are the ultimate process for the sake of process. Such a bikeshedding waste of time. Such policies serve absolutely no objective purpose. They're only there to satisfy some leader's asthetic senses and feeling of control.

As for easier to read thousands of newspaper headlines and magazine article titles provide strong evidence otherwise. Even HN itself is proof it doesn't matter

Post reply on HN