Semantic Git Commit Messages | Hacker News Reader

Semantic Git Commit Messages

gist.github.com

20 pointssamrohn77721 comments

I don't get it? It's just a weak summary of Conventional Commits without any context.

https://www.conventionalcommits.org/

First of all, the linked gist doesn't provide any new information. It states "See how a minor change to your commit message style can make you a better programmer." then proceeds to say nothing on that topic.

Putting all that aside. I've used the conventional commit format in many of my projects. So far, I've found that without a tool to handle the format for me, I am simply too lazy to sustain that format for more than a few days.

Also, there become situations where your commits contain new code for multiple features that are all related. Or, there are times when I am simply committing code before completing a feature just in case I want to roll something back.

In these cases, there often isn't a good "type" that optimally covers the full scope of what is occurring.

It seems that many of the things we do as programmers are just superfluous ways of "making things easier" or "more organized" that ultimately just waste time and result in unfinished projects.

> I've found that without a tool to handle the format for me, I am simply too lazy to sustain that format for more than a few days.

That tool is Git, it's already built-in. You can create a Git commit template, with the correct format, and then in the comments of the template you list out the semantic options for quick reference.

See `commit.template` here: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configura...

I use this style. It’s been very helpful. It feels like a nice scannable breadcrumb compared to my old commit titles. I did have trouble sometimes remembering the categories. Was it “doc” or “docs”? So I changed my git template to show this and my own enshrined categories. One category I added was “excise” for the removal of things.

https://gist.github.com/shanecelis/db3f348288be70e4de4e0f249...

Early on in, I used to write “refactor,doc,feature:” before I realized that one of the practices this is meant to encourage is a commit that does one of the things, not all of them. I’m not very strict about it. I always do the semantic title but if I have some documentation mingled with a refactor, oh well.

What's the value of this? My work enforces this and it is such a drag, it's incredible how negatively it impacts my productivity

Current team squashes PRs, so the individual commits are not super important, and it's only the title of the PR that needs to be semantic. Works pretty well for us.

How does it impact productivity?

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?

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.

Assuming committers adhere to it, there could be some interesting use cases when combined with a tool like AskGit (https://github.com/askgitdev/askgit) for understanding what "categories" of work is being done in a codebase.

Maybe even what directories/files tend to see `fix` or `refactor` more frequently (signs of a poorly design or "hot" area?)

Especially great when combined with https://github.com/semantic-release/semantic-release

Also just ran across this, looks interesting: https://github.com/zeke/semantic-pull-requests

Don’t use ”style” when you mean ”formatting”, frontenders can confuse it with CSS styling tasks.

(Why are you formatting code by hand anyway? Automated tools exist for that.)

They should go outside their small world, then.

Maybe that would be prudent for someone else.

From my experience, backend is the ”small world” where interfaces are known and solutions relatively stable.

Frontend, on the other hand, requires all the same programming skill, but is basically a set of different black boxes that kinda sorta implement the same interfaces in an almost compatible manner, with new ones added regularly and others deprecated, and every 12-36 months a completely new paradigm arrives.

The same can be said in the opposite direction..?

This just makes commits about Project Management (tracking) and not about Development (reasoning).

Diffs say what you did. Commits should say why you did.

No one uses semantic email subjects, why this? What is the value added?

If this is an excuse to autogenerate your changelog, no thank you.

So what would you do to generate them?

I don't. Write the CHANGELOG as you go. If you are worried about merge conflicts, drop separate files in a folder.

Anything editable/commentable is better than using immutable commit metadata to author an important part of your documentation.

Reply on news.ycombinator.com