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?)
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.
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.
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.
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.
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.
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.
21 comments
[ 4.3 ms ] story [ 64.5 ms ] threadhttps://www.conventionalcommits.org/
Maybe even what directories/files tend to see `fix` or `refactor` more frequently (signs of a poorly design or "hot" area?)
(Why are you formatting code by hand anyway? Automated tools exist for that.)
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.
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'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.
If this is an excuse to autogenerate your changelog, no thank you.
Anything editable/commentable is better than using immutable commit metadata to author an important part of your documentation.
Diffs say what you did. Commits should say why you did.
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.
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...
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.
Also just ran across this, looks interesting: https://github.com/zeke/semantic-pull-requests