Motivation of this blog is to curate all information at one place and to make more people aware about standards followed by industry.
Let's get started.....
A typical git commit message will look like
<type>(<scope>): <subject>
"type" must be one of the following mentioned below!
-
build: Build related changes (eg: npm related/ adding external dependencies) -
chore: A code change that external user won't see (eg: change to .gitignore file or .prettierrc file) -
feat: A new feature -
fix: A bug fix -
docs: Documentation related changes -
refactor: A code that neither fix bug nor adds a feature. (eg: You can use this when there is semantic changes like renaming a variable/ function name) -
perf: A code that improves performance -
style: A code that is related to styling -
test: Adding new test or making changes to existing test
"scope" is optional
- Scope must be noun and it represents the section of the section of the codebase
- Refer this link for example related to scope
"subject"
- use imperative, present tense (eg: use "add" instead of "added" or "adds")
- don't use dot(.) at end
- don't capitalize first letter
Refer this link for more practical examples of commit messages
Latest comments (54)
This tool makes doing this very simple: itnext.io/writing-better-commits-6...
Commit formats are a lot like linting rules. Some can be very strict, some can be very freeform.
The lesson here is that no matter what format you use, people can still have terrible commit messages.
fix(stuff): updatesis a valid conventional commit format, but a useless commit message.While conventional commit formats can help with breaking up commits (doc commits should be separate from style commits), it's important to try to keep commits atomic and transactional.
I have read this before from Conventional Git commits website, but you have broken it down better for me, thank you!
I want to add "revert".
I like most of this, but should not unit tests come along with the code (in the same commit)? I would also prefer "feature" over "feat".
It's helpful to me, thank you for this!
If you are using Jet Brains IDEs for development, you can use the following plugin to create commit messages according to this convention easily. Check it out
plugins.jetbrains.com/plugin/9861-...
Nice article, i already used this, but i never read about
I think this convention is nice for open-source projects but requires a lot of discipline to keep the commits atomic.
On an enterprise level where there is a task tracking system, I prefer to follow standard of `TASK-ID: ...' as most of the git ui softwares can link the tickets in project management tool.
Both works great in general but sometimes I really like to dig deeper to see the reasoning behind a change.
Thank you for the article.
A quick suggestion, you need to change this link
https://github.com/eslint/eslint/commits/mastertohttps://github.com/eslint/eslint/commits/main. Otherwise it's giving 404.Thanks for sharing, didn't see it in a list for quite a while. As documentation should relate 1:1 to code, I don't think "docs" should be a type. What about a bug in the docs? What about business rules changing? Use-case changing and the commit is about implementing it? Docs should go as there should hardly be any code change without doc-change and vice versa. Also feature looks a lot better than feat.
Thanks again for sharing, it is an important subject.
Just use github.com/conventional-changelog/...
Git-cz
I have a question , IS it possible to have multiple types in a single commit message
That should make the commits composite instead of atomic, which we maybe want to avoid.
its a good practice to have atomic commits. Commit as small as a change can be labeled. Later you can git squash them in one big commit having release tag or feature tag
Yes, a good way of forcing better commits to only allow one scope.
what about type: WIP for Work in progress. Do anyone use it like me?