Hacker News Reader

Not GP, but I generally find it troublesome to categorize some commits: if I implement a feature by refactor, and document the new feature, which of the topics should I use? Or should I artificially break the commits up, even if they make more sense as one atomic change?

View on HN

definitely feat, since it would indicate an end-user experience change whereas docs and refactor would not.

If you think in terms of semver and changelog autogeneration, these questions have obvious answers. ofc there are also other benefits like improved communication with teammates and contributors (and the curious).

I see your point. But what is the consequence for making "the wrong choice"? (I don't think there is a wrong choice). Will you be scolded? Will anyone even notice?

I've never worried about making the wrong choice. I've never spent more than 5 seconds choosing a commit category. It should just be a best-effort system, that adds a bit of Metadata, structure and clarity to commit messages. The many teams I've seen with "wip, wip, wip, fix, fixing class" commit messages in PRs surely isn't aiding code review.

You can just label everything a "chore"... because it is.

Reply on news.ycombinator.com