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:
Top comments (17)
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.
Thanks for the comment, I have updated the article adding your inputs and why I mentioned that one linear messages are preferable.
But, in reality, most pros write them like this:
😜
Quite true, even if we shouldn't 😂.
But we are working on it...
That's why we are here to change the reality. Happy Committing Jon.
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.
Thanks for the comment, I have updated the article adding your inputs.
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.
Haha That's funny reading those commit messages.
Thank you @ritikbanger...very helpful article
Thank you @shubhamsigdar
Well written!
Thanks @geazi_anc
very helpful
Thanks @mnish9
Thanks Ritik,
For providing such informative stuff.
Thanks @rawasthi231