8 ms·

Semantic Git Commit Messages

20 points by samrohn777 5y ago

jasonpeacock 5y ago
I don't get it? It's just a weak summary of Conventional Commits without any context. https://www.conventionalcommits.org/ https://www.conventionalcommits.org/
patrickdevivo 5y ago
Assuming committers adhere to it, there could be some interesting use cases when combined with a tool like AskGit (https://github.com/askgitdev/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?)
eurasiantiger 5y ago
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.)
- nikolay 5y ago
  They should go outside their small world, then.
  - BossingAround 5y ago
    The same can be said in the opposite direction..?
  - eurasiantiger 5y ago
    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.
activitypea 5y ago
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
- ttymck 5y ago
  How does it impact productivity?
  - q3k 5y ago
    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?
    - mrorbitman 5y ago
      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).
    - ttymck 5y ago
      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.
      - icedchai 5y ago
        You can just label everything a "chore"... because it is.
remram 5y ago
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.
- aairey 5y ago
  So what would you do to generate them?
  - remram 5y ago
    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.
bnix 5y ago
This just makes commits about Project Management (tracking) and not about Development (reasoning). Diffs say what you did. Commits should say why you did.
yooogle 5y ago
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.
- jasonpeacock 5y ago
  > 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-Configuration https://git-scm.com/book/en/v2/Customizing-Git-Git-Configura...
shizzy0 5y ago
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/db3f348288be70e4de4e0f2493f4e3d1 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.
difosfor 5y ago
Especially great when combined with https://github.com/semantic-release/semantic-release https://github.com/semantic-release/semantic-release Also just ran across this, looks interesting: https://github.com/zeke/semantic-pull-requests https://github.com/zeke/semantic-pull-requests

20 points by samrohn777 5y ago

I don't get it? It's just a weak summary of Conventional Commits without any context. https://www.conventionalcommits.org/ https://www.conventionalcommits.org/

patrickdevivo 5y ago

Assuming committers adhere to it, there could be some interesting use cases when combined with a tool like AskGit (https://github.com/askgitdev/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?)

eurasiantiger 5y ago

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

nikolay 5y ago
They should go outside their small world, then.
- BossingAround 5y ago
  The same can be said in the opposite direction..?
- eurasiantiger 5y ago
  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.

activitypea 5y ago

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

ttymck 5y ago
How does it impact productivity?
- q3k 5y ago
  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?
  - mrorbitman 5y ago
    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).
  - ttymck 5y ago
    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.
    - icedchai 5y ago
      You can just label everything a "chore"... because it is.

remram 5y ago

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.

aairey 5y ago
So what would you do to generate them?
- remram 5y ago
  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.

bnix 5y ago

This just makes commits about Project Management (tracking) and not about Development (reasoning). Diffs say what you did. Commits should say why you did.

yooogle 5y ago

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.

jasonpeacock 5y ago
> 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-Configuration https://git-scm.com/book/en/v2/Customizing-Git-Git-Configura...

shizzy0 5y ago

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

difosfor 5y ago

Especially great when combined with https://github.com/semantic-release/semantic-release https://github.com/semantic-release/semantic-release Also just ran across this, looks interesting: https://github.com/zeke/semantic-pull-requests https://github.com/zeke/semantic-pull-requests