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

[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]

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.

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

[Martin Jablečník]

Yes I am using Commitizen for creating of this type git messages. :)

[Ben Force]

It gets even better when you combine it with semantic-release!

[mludovici]

is this a real used "convention" in general or just another new thing?

[Sergey Kislyakov]

I had been using this style at my job before we moved to BitBucket. We're using $JIRA-ID $JIRA-TITLE now. And I've seen many public GitHub repos following this (feat(scope): message) convention.

[nbulba]

It looks pretty cool and I see how this may come in handy.

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

[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".

[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!!

[Jaime López]

I'm following the same guidelines but read from this page karma-runner.github.io/5.2/dev/git...

[Reard]

This link should also be helpful: conventionalcommits.org

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

[Wanderley]

simple, straightforward and very practical. Thanks for sharing.

can i write a post in portuguese, making due reference to yours?

[Ishan Makadia]

Yes go ahead.. Thank You

[Wanderley]

Thank You

[Wanderley]

it's alive

dev.to/wanderleyfa/git-commit-uma-...

[Neil Hickman]

We actually developed a release system following conventional commits that actually analyse the type contained in commits since the last deployment. It would affect semver in different ways such as feat types would bump minor versions, fixes would bump patch versions and breaking changes would bump major versions. We also use commitlint in order to enforce the conventional commits standard.

[Abdulla T]

Nice post. I have a follow up question and Im interested in how its done in different companies.

Suppose you have a big feature that involves infra change, refactoring, new dependency and new styles, basically a big cocktail of the commits that are all connected. Normally some wld commit to a branch then do a PR, but in this situation since these all commits serve a single feature the commits will get squashed into one commit before its merged to the main branch. I guess the squashed commit will use the proper convention message that you described, but those individual commits dont matter, unless your company enforces PR review per commit? I know that some big companies wld even enforce a commit per each function/block/file and each commit requires a PR review. But these PR reviews are so quick bcz they are on small commits.

What other practices ppl have used/dealt with, and which ones do ppl prefer?

[J. G. Sebring]

feat or breaking, but theses kind of changes should be taken seriously when writing the commit message, I've sometimes used commit messages (from the squash) inside the message of the actual feat commit.
like

feat: adds authorization

Adds OATH bla bla... 
refactor: adds authorization to protected pages
refactor: redirect to login page

[VyRru5]

i prefer to use Gitmoji to prefix my commit message
gitmoji.dev

[macdevign]

For those who are using keyboard maestro (keyboardmaestro.com),
you can automate enter these 'types' from selection popup, (can select multiple types by CMD key)

Have added the macro in this KM forum
forum.keyboardmaestro.com/t/macro-...

If you interested , can download the macro there.