DEV Community

Cover image for How to write Git commit messages like a Pro!
Ritik Banger
Ritik Banger

Posted on


How to write Git commit messages like a Pro!

When a developer go back into time to look for something he has worked on six months ago, many times he does not understand why he made that particular commit and the only reason is that he has not followed the right way to write the commit message.

There are commit message standards that devs practice around the world, and it is good to follow popular standards so that when you come back after a good amount of time or someone else looks at your commit messages, it would not look like cringe!

The most effective technique to inform other developers of the context of a change is with a well-written Git commit message.

Teams should first decide on a commit message convention that specifies the version control history of the product they are building.

A great Git commit message should have a proper style, content, and the metadata.

A known Git commit follows this convention:

<type>(<scope>): <message>

<type> can be one of the following:

  • feat for a new feature.
  • refactor for refactoring production code, e.g. renaming a function.
  • docs for changes to the documentation.
  • fix for a bug fix for the user.
  • perf for performance improvements.
  • style for formatting changes, missing semicolons, etc.
  • test for adding missing tests, refactoring tests.
  • build for updating build configuration, development tools or other changes irrelevant to the user.

You can also add your custom type too, depending on the standards your team follows. The above standards are followed by ESlint team. You can check their commit messages here.

The scope is optional, and the message part should include a single line statement, not more than 72 characters, to sum up what the commit is for.

Many developers also use the message as the subject line and add a body too, that is basically the description of the commit, but a one-liner commit message is preferable as long as you can tell about the context (commit what's and why's), if the commit demands a more detailed description that can not be explained in a single line, commit body is always necessary.

You can also use tools like Glitter or Commitizen to standardize your commit messages.

Not only this, You might also wonder that there is a tool that checks for your commit message and pops an error if it does not follow the guidelines. Commit lint is one of them. It helps your team adhere to a commit convention.

Many times, industry experts use their JIRA or Click Up ticket as the commit message so that everything can be link or trace back anytime and the codebase remain maintainable for future developers.

Some teams also like to add emoji to their commit messages. I have curated a list of emojis and their respective meanings, you can check it out here.

At the end, the important thing is that your commit message should be meaningful and does not confuse your fellow developers or the future developers about what a particular change is up to.

If you wish to learn more about conventional commits, semantic commits, or the practices that industry follows, here are some resources for you:

  1. Conventional Commits

  2. Semantic Commits

  3. How to write a commit message by CBeams

Latest comments (17)

arcticllama profile image
ArcticLlama • Edited

This reminded me of Commit Logs From Last Night. It apparently got shut down and redirected. There is a version of it here or here (Twitter feed).

My favorite is when frustrated developers fight in the commit messages.

ritikbanger profile image
Ritik Banger

Haha That's funny reading those commit messages.

shubhamsigdar profile image
Shubham Sigdar

Thank you @ritikbanger...very helpful article

ritikbanger profile image
Ritik Banger

Thank you @shubhamsigdar

geazi_anc profile image
Geazi Anc

Well written!

ritikbanger profile image
Ritik Banger

Thanks @geazi_anc

jonrandy profile image
Jon Randy ๐ŸŽ–๏ธ • Edited

But, in reality, most pros write them like this:

Fixes stuff
Enter fullscreen mode Exit fullscreen mode


oanouman profile image
Martial Anouman • Edited

Quite true, even if we shouldn't ๐Ÿ˜‚.
But we are working on it...

ritikbanger profile image
Ritik Banger

That's why we are here to change the reality. Happy Committing Jon.

darkwiiplayer profile image
๐’ŽWii ๐Ÿณ๏ธโ€โšง๏ธ

but a one-liner commit message is preferable.

Absolutely not!

Whether adding fancy metadata to the commit summary is useful or adds clutter is arguable, but saying that adding a well-written commit description below should preferably be skipped is just a very dumb take.

Always always always add as much context as necessary. Whether this means you add one more sentence to clarify why the change was necessary, or add a full description of how a bug was identified, anything that can help another developer figure out why a change was made is valuable information.

ritikbanger profile image
Ritik Banger

Thanks for the comment, I have updated the article adding your inputs.

cappe987 profile image

... a one-liner commit message is preferable.

I disagree with this. You said it yourself, a commit should explain why a change was made. Be it due to a bug, or to prepare for a new feature, or anything else. The title (first line) should be as you say, short and concise about what the commit does. But the commit body should contain more detailed reasons why. Explain the original bug or give an example on how to use the new feature.

I'm not saying every commit needs this. Sometimes line is enough. But far from always.

ritikbanger profile image
Ritik Banger

Thanks for the comment, I have updated the article adding your inputs and why I mentioned that one linear messages are preferable.

mnish9 profile image

very helpful

ritikbanger profile image
Ritik Banger

Thanks @mnish9

rawasthi231 profile image
Raghvendra Awasthi

Thanks Ritik,
For providing such informative stuff.

ritikbanger profile image
Ritik Banger

Thanks @rawasthi231

Super Useful CSS Resources

A collection of 70 hand-picked, web-based tools which are actually useful.
Each will generate pure CSS without the need for JS or any external libraries.