Git commit message convention that you can follow!

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

References:

• https://www.conventionalcommits.org/en/v1.0.0/
• https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716
• https://github.com/fteem/git-semantic-commits

Comments

[Elliot Nelson]

This post is a good intro to conventional commits, but I guess I don't agree that this is a "standard" -- it's popular, but I'd say less than 20% of git projects overall use conventional commits.

Just remember to look at what the typical commit looks like in a project before committing and try to follow suit. For smaller fun projects you might run into gitmoji, for corporate projects a ticket Id + summary style is common, etc.

[Milo]

Cool! I use this one for a few of my projects, I also wrote a tool that simplifies it called glitter, it allows you to scaffold a commit message very simply, here is a link: github.com/Milo123459/glitter - thanks, and this is quite a helpful post for a few of my friends getting into git and version management!

[Ishan Makadia]

Glitter is awesome.. Good efforts
Also, I am glad that it will help your friends:)

[Milo]

Haha, thank you!

[Martin Jablečník]

What can give me your glitter in compare with commitizen which I am using right now?

[Milo]

Oh, the type of message is customisabe. For example,
$1: $2: $3+

If you give the arguments:
hello world how are you
It'd be:
hello: world: how are you

Etc, you can change it to however you like, I don't think CZ can do that.

[Milo]

As far as I see, there isn't much of a difference. I'm working on interactivity for it (and that is no easy feat!) but yea, not much to change. I think the only big difference is the custom sub-command / scripts feature.

[Jonathan Irvin]

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): updates is 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.

[Andrew Clayton]

Heh, you forgot the most important part, the actual message! (and no, the subject isn't it, most of the time anyway).

The message is what you'll look at in six months time to figure out why you did something.

If I need to inform people about good commit messages I usually just point them to the Linux kernel.

[Rahoul Baruah]

What's the benefit?

I mean I can see the immediate benefit - but if I was trying to figure out why a change was made I would probably need more than perf or fix; the link back to the original ticket would be more useful.

[Ishan Makadia]

Yeah.... I didn't mention this practical use case in my article.
People can actually link their JIRA Ticket and that would be more useful.
Rightly said!!

[Minh Nguyen]

One cool way to commit is to use emojis. I used emojis as my own types of commits. Check this out.
gist.github.com/minhnguyen0712/178...

[Pankaj Patel]

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.

[K M H Mubin]

Hey,
Thank you for this cool post. I learn new stuff.
So, I have a question, and It will be beneficial for me if you answer it.
I'm new to the git commit message. Here is the scenario,
"Suppose I create a new Car Class file and wrote the code inside that file. Now I want to commit this class file. "

The question is in the git commit message which type is it? (refactor or other). If possible, give an example.

Thank you for your generous answer.

Note: If I make any mistake in English, please forgive me.

[Ishan Makadia]

Hey
I think you shouldn't use refactor

As you are creating new Car Class from scratch. I believe that it will add some feature to your application.
As a result you can use "feat:"
OR
If you feel that "feat:" is not the exact match then you can decide your own <type> and start using it.

For Example:
EsLint have decided there own <type> for commit message. So it's totally upto you or organization you work for.

Refer ESLint:
You can see below <type> which are used by ESLint at eslint.org/docs/developer-guide/co...

Fix - for a bug fix.
Update - either for a backwards-compatible enhancement or for a rule change that adds reported problems.
New - implemented a new feature.
Breaking - for a backwards-incompatible enhancement or feature.
Docs - changes to documentation only.
Build - changes to build process only.
Upgrade - for a dependency upgrade.
Chore - for refactoring, adding tests, etc. (anything that isn't user-facing).

[K M H Mubin]

Thank you for your insightful information. I really appreciate it. 😊

[Mirco Bellagamba]

I would add this article to the list.
chris.beams.io/posts/git-commit/
I found it very clear about how to write a good commit message. In this commit format, the rules described could be applied to the "subject".

[MorenoMdz]

Why? I get why having a pattern helps to read the structure, but why the convention on adds, vs add vs Add for example? It also limits for those that want to work differently, for example add a feature and style changes in the same commit.

[J. G. Sebring]

Well, one point is to remove the "work differently" part. =)

Same as why having code convention. You can argue that it limit those who prefer new line before the { but that is also exactly the point. You can express personality in your editor by changing font, using dark mode or whatever, but you shouldn't really do it in code or commit messages.

adds vs add

You describe the commit, not "what you have done". Just as documentation of a function is what the function does, if called.

The commit is chang*ing* the behaviour of your program, it resolves a bug or adds a feature. You can consider the list of git log as a list of events (or functions) that build your code base.