When to use "chore" as type of commit message? [closed]

Question

What is the use of chore in semantic version control commit messages? Other types like feat or fix are clear, but I don't know when to use "chore".

Can anyone provide a couple of examples of its use?

Another maybe not related question: What's the proper type of commit messages for modifying files like .gitignore?

Indogermanic

Answer 1

You can see a short definition in "Git Commit Msg":

chore: updating grunt tasks etc; no production code change

It is used in:

• "Semantic Commit Messages" and in

• the project "fteem/git-semantic-commits".

     git chore "commit-message-here" -> git commit -m 'chore: commit-message-here' 
  

Modifying the .gitignore would be part of the "chores".

"grunt task" means nothing that an external user would see:

• implementation (of an existing feature, which doesn't involve a fix),
• configuration (like the .gitignore or .gitattributes),
• private internal methods...

Although Owen S mentions in the comments:

Looking at the Karma page you link to, I suspect that grunt task may refer specifically to Javascript's build tool grunt.
In which case, they probably didn't have in mind changes involving implementation or private internal methods, but rather tool changes, configuration changes, and changes to things that do not actually go into production at all.
(Our shop currently uses it for those, and also for simple refactoring.)

Conspicuous

I already read the link you provided. Actually it was the only thing I found! But I don't get what does grunt tasks mean. Can you provide some examples? – Indogermanic

@AlirezaMirian I have added some examples for "grunt tasks". – Conspicuous

Looking at the Karma page you link to, I suspect that grunt task may refer specifically to Javascript's build tool grunt. In which case, they probably didn't have in mind changes involving implementation or private internal methods, but rather tool changes, configuration changes, and changes to things that do not actually go into production at all. (Our shop currently uses it for those, and also for simple refactorings.) – Chandelle

@OwenS. Interesting. I have included your comment in the answer for more visibility. – Conspicuous

I'd like to amend to this answer and point out that it includes some of the commits that would fall under build as well since build commits are not seen by the user. It remains a good explanation, just missing out an exception rule. – Towards

@Conspicuous plot twist.. I just checked out the link that you included, from Karma, and the link that the OP included. none has 'build' listed. I am familiar with the Angular convention, which does include the 'build' commit type. Not sure now if an edit is warranted except to point out that the angular convention has an additional different commit type – Towards

@nxmohamad Agreed. No need for an edit in that case, but good comment. – Conspicuous

should I use chore while changing a configuration file? like modifying env variables or adding a new dev environment directory? – Nosy

@Nosy Not if those changes have a visible impact to the external user, so it depends on the nature of what you are changing. – Conspicuous

Should chore trigger a new patch release? – Haemal

@Haemal It could indeed, depending on your release workflow. But not automatically, as it could be part of a larger set of changes, some of them warranting minor or even major release. – Conspicuous

@Conspicuous Thanks. If you would just re-organise some folders or add some missing tests. Would you do this chore on main, beta or alpha? – Haemal

@Haemal not on main directly, always on an integration branch through a pull request from a topic branch. – Conspicuous