DEV Community

loading...
Cover image for Git commit message convention that you can follow!

Git commit message convention that you can follow!

i5han3 profile image Ishan Makadia ・1 min read

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>
Enter fullscreen mode Exit fullscreen mode

"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

"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:

Discussion (42)

pic
Editor guide
Collapse
7tonshark profile image
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.

Collapse
milo123459 profile image
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!

Collapse
i5han3 profile image
Ishan Makadia Author

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

Collapse
milo123459 profile image
Milo

Haha, thank you!

Collapse
mjablecnik profile image
Martin Jablečník

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

Collapse
milo123459 profile image
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.

Collapse
milo123459 profile image
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.

Collapse
kmhmubin profile image
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.

Collapse
i5han3 profile image
Ishan Makadia Author

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).
Enter fullscreen mode Exit fullscreen mode
Collapse
kmhmubin profile image
K M H Mubin

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

Collapse
rahoulb profile image
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.

Collapse
i5han3 profile image
Ishan Makadia Author

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

Collapse
mbellagamba profile image
Mirco Bellagamba • Edited

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

Collapse
ac000 profile image
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.

Collapse
minhnguyen0712 profile image
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...

Collapse
morenomdz profile image
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.

Collapse
sebring profile image
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.

Collapse
macdevign profile image
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.

Collapse
llanilek profile image
Neil Hickman • Edited

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.

Collapse
abbadev profile image
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?

Collapse
sebring profile image
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
Enter fullscreen mode Exit fullscreen mode
Collapse
ssousa profile image
Sofia Sousa

Already read a few posts about this topic and it's very common to find some misunderstanding with the "style" type.

For some conventions "style" type stands for "Formatting, missing semi colons, etc; no code change", which makes more sense to me. This kind of changes doesn't fit into any of the other types (it's not refactor, or a feature or chore). In the other hand, style and layout changes for example can fit in "feat" type, in my opinion.

Which type of this convention do you choose for code styling changes?

Collapse
huzaifa99 profile image
Huzaifa Rasheed

I usually use lint in place of style because that is what it is doing. Just some personal preference

Collapse
nbulba profile image
nbulba

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

Collapse
wanderleyfa profile image
Wanderley

simple, straightforward and very practical. Thanks for sharing.

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

Collapse
i5han3 profile image
Ishan Makadia Author

Yes go ahead.. Thank You

Collapse
wanderleyfa profile image
Collapse
wanderleyfa profile image
Wanderley

Thank You

Collapse
hseritt profile image
Harlin Seritt

I like it. Thanks for sharing!

Collapse
jeankaplansky_42 profile image
Jean Kaplansky

Thanks for putting this all in one place! I can NEVER remember the conventionalcommits.com site.

Collapse
thekardynal profile image
thekardynal4

This link should also be helpful: conventionalcommits.org

Collapse
jaloplo profile image
Jaime López

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

Collapse
mjablecnik profile image
Martin Jablečník

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

Collapse
thebenforce profile image
Ben Force

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

Collapse
mrdulin profile image
Collapse
andy3520 profile image
andy3520

what about type: WIP for Work in progress. Do anyone use it like me?

Collapse
johnthad profile image
Thad Humphries

Thanks. I'd seen this list before but no explanation.

Collapse
vyrru5 profile image
VyRru5

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

Collapse
anonymousm profile image
mludovici

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

Collapse
defman profile image
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.

Collapse
mikaleb_77 profile image
Mikaleb

Git-cz

Collapse
towbee98 profile image
Tobiloba

I have a question , IS it possible to have multiple types in a single commit message