314

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?

Alireza Mirian
  • 5,862
  • 3
  • 29
  • 48

2 Answers2

348

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

chore: updating grunt tasks etc; no production code change

It is used in:

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

neaumusic
  • 10,027
  • 9
  • 55
  • 83
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 3
    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? – Alireza Mirian Nov 15 '14 at 10:33
  • @AlirezaMirian I have added some examples for "grunt tasks". – VonC Nov 15 '14 at 11:09
  • 28
    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.) – Owen S. May 05 '15 at 06:25
  • 1
    @OwenS. Interesting. I have included your comment in the answer for more visibility. – VonC May 05 '15 at 06:30
  • 2
    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. – nxmohamad Nov 13 '17 at 06:01
  • 2
    @VonC 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 – nxmohamad Nov 13 '17 at 11:52
  • @nxmohamad Agreed. No need for an edit in that case, but good comment. – VonC Nov 13 '17 at 12:33
  • should I use chore while changing a configuration file? like modifying env variables or adding a new dev environment directory? – predator2v0 Apr 05 '22 at 18:58
  • @predator2v0 Not if those changes have a visible impact to the external user, so it depends on the nature of what you are changing. – VonC Apr 05 '22 at 21:59
  • Should `chore` trigger a new `patch` release? – cbdeveloper Nov 03 '22 at 06:43
  • 1
    @cbdeveloper 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. – VonC Nov 03 '22 at 07:28
  • @VonC Thanks. If you would just re-organise some folders or add some missing tests. Would you do this `chore` on `main`, `beta` or `alpha`? – cbdeveloper Nov 03 '22 at 09:33
  • 1
    @cbdeveloper not on main directly, always on an integration branch through a pull request from a topic branch. – VonC Nov 03 '22 at 10:11
13

In the context of Git commits, these terms are often used as part of commit messages to provide a concise description of the changes made in a commit. Using a consistent structure for commit messages helps improve code collaboration and makes it easier to understand the purpose of each commit. The commonly used prefixes in commit messages are as follows:

  1. feat: Short for "feature," this prefix is used when introducing a new feature or functionality to the codebase. For example:

    feat: Add user authentication feature

  2. chore: This prefix is used for commits related to maintenance tasks, build processes, or other non-user-facing changes. It typically includes tasks that don't directly impact the functionality but are necessary for the project's development and maintenance. For example:

    chore: Update dependencies
chore: Refactor build script

  3. fix: Used when addressing a bug or issue in the codebase. This prefix indicates that the commit contains a fix for a problem. For example:

    fix: Correct calculation in revenue calculation

  4. docs: Used when making changes to documentation, including comments in the code, README files, or any other documentation associated with the project. For example:

    docs: Update API documentation

  5. style: This prefix is used for code style changes, such as formatting, indentation, and whitespace adjustments. It's important to separate style changes from functional changes for better clarity. For example:

    style: Format code according to style guide

  6. refactor: Used when making changes to the codebase that do not introduce new features or fix issues but involve restructuring or optimizing existing code. For example:

    refactor: Reorganize folder structure

  7. test: Used when adding or modifying tests for the codebase, including unit tests, integration tests, and other forms of testing. For example:

    test: Add unit tests for user authentication

  8. perf: Short for "performance," this prefix is used when making changes aimed at improving the performance of the codebase. For example:

    perf: Optimize database queries for faster response times

These prefixes help create a standardized way of categorizing and understanding the nature of the changes made in a commit. They contribute to better communication and collaboration among developers working on a project, making it easier to review and track changes over time.

Ajith S Nair
  • 147
  • 1
  • 5