DEV Community

Cover image for Write Clear and Meaningful Git Commit Messages
Ashish Patel
Ashish Patel

Posted on • Updated on

Write Clear and Meaningful Git Commit Messages

There are no strict rules for writing commit messages but When working on a project on GitHub, it's important to communicate clearly and concisely about the changes you've made. One way to do this is through the use of keywords in your commit messages.

These keywords, or labels, help to indicate the nature of the changes and make it easier for others to understand the context of your contributions.

Here are some common keywords and what they indicate:

FEAT: Use this keyword to indicate that you are committing to a new feature.

"FEAT: Add new login functionality."

FIX: Use this keyword to indicate that you are committing a fix for a specific problem or issue.

"FIX: Fix bug causing crashes on certain devices."

STYLE: Use this keyword to indicate that you are making changes to the style or formatting of the code, but not its functionality.

"STYLE: Update indentation in main.js."

REFACTOR: Use this keyword to indicate that you are making changes to the code that improve its structure or organisation, but do not add new features or fix bugs.

"REFACTOR: Refactor the code to improve readability."

TEST: Use this keyword to indicate that you are adding or updating tests for the code.

"TEST: Add new unit tests for login functionality."

CHORE: Use this keyword to indicate that you are making changes to the build process or other tasks that are not directly related to the code itself.

"CHORE: Update dependencies in package.json."

PERF: Use this keyword to indicate that you are making changes to improve the performance of the code.

"PERF: Optimize image loading for faster performance."

CI: Use this keyword to indicate that you are making changes to the continuous integration process.

"CI: Fix issue with test pipeline on Dashboard CI."

BUILD: Use this keyword to indicate that you are making changes to the build process.

"BUILD: Add new script for building the production version of the app."

By using these keywords in your commit messages, you can help to make your contributions more clear and more understandable to others. However, it is important to note that these are just suggestions and not all projects use them, it's important to check the project's documentation to see if there are any specific guidelines you should follow.

In summary, clear and concise commit messages are a key aspect of good development practices. Using keywords in your commit messages can help to indicate the nature of the changes you've made, making it easier for others to understand and review your contributions.

My Other Blogs
BEM Methodology for CSS - A Guide for Developers

Latest comments (33)

Collapse
 
abewartech profile image
abewartech

Image description

I now use the gitmoji extension in vs code

Collapse
 
dipeshjaiswal profile image
Dipesh Jaiswal

Lorddddd!!!!!

Collapse
 
qq449245884 profile image
qq449245884

Dear Ashish Patel,may I translate your article into Chinese?I would like to share it with more developers in China. I will give the original author and original source.

Collapse
 
ashishxcode profile image
Ashish Patel

Yeah Sure, Happy to help

Collapse
 
marcelin97 profile image
Loïs MARCELIN

can you share your commission naming method with emoji
Thank you

Collapse
 
ashishxcode profile image
Ashish Patel

FEAT: 🚀
FIX: 🛠️
STYLE: 💄
REFACTOR: 🔧
TEST: 🧪
CHORE: 🧹
PERF: 🏎️
CI: 🚦
BUILD: 🏗️

Collapse
 
marcelin97 profile image
Loïs MARCELIN

Than you very much 🫡

Collapse
 
neumatic_78 profile image
neu-ma-tic

haha keyboard go brrrrr

Collapse
 
ashishxcode profile image
Ashish Patel

Haha 😅

Do share this blog with your team

Collapse
 
rleddy profile image
Info Comment hidden by post author - thread only accessible via permalink
Richard Leddy • Edited

It has been my experience that people overthink this.

I had a battle with some guy who was just trying to get me fired so that he could hire his buddies. So, he had ridiculous rules about commits. And, he made an issue of it over and over. Yet, if I fixed the company's programs so that they were not fired by big money (company is Google or other in the same ball park), then he would get very upset and get more petulant about commits more than ever.

In the end, his git commit tyrany was not even well thought out. Even so, he did get his way with me on the grounds that I did too much work and that was too much of a bother for him, even though that wasn't exactly his job. But, the druken managers did his bidding when he wrote long letters.

Don't weaponize commit message!

So, here is a problem.:

Things like github are nice micro step backup engines. Commit as often as possible in case your computer crashes - as it will.

(Here I am with a disk drive I installed after the last one fried -- and I was lucky that had done an actual backup not long before. It's about the third battery. Don't forget that for abstract math and computer software that you should know how to use a screw driver and a sodering iron. You should fix your car, too. Because, jackasses don't pay enough for your great toil writing software.)

So, write fuzzy little commit message to yourself most of the time. Write many obscure indecipherable comments for each little commit.

But, some commits are more improtant than others. They mark the point that you really want to join the rest of the world. That means your stuff should be tested. Right!? So, you mark the publishable commit. You make that searchable as possible.

All you really need is some meaningful and unique marker. And, your upstream should be nice about it. They should not be telling you how many commit messages you can have since your last merge. There should be nothing artificial in preping for the next advance.

It is poor repository management to hit someone with a detraction like, "Your commit comment should be more beautiful." Like, what! And, what vector for beautiful should we be talking about? And, if I try to make it more beautiful, will you behold the next version as such or will you just complain to mangement that I can't cut the beauty contest of commit messages?

No doubt, cures for cancer and the end of world hunger have been tossed out by control freaks who just need to boss people around with vageries over things like commit messages.

More focussed on what is being discussed here:

So, this is a nice idea, the marking of absolute purpose. It would be best if such markers were made available in github desktop or other tools. Maybe git comments could allow classification symbols. But, maybe a symbol along the lines of "I JUST DON'T WANT TO THINK ABOUT THIS RIGHT NOW!" might be in the list as well. Of course, that would not be for publishable versions. But, really... It grows old really fast.

However, I am on board with the basic idea. And, I usually put in some words that indicate the degree of importance of the commit. For insance, "STUPID COMMA!" is a good one. "I THOUGHT I SAVED IT FIRST" is another. And, there are many other possibilities.

Best if a git comment analyzer actually did NLU. That might actually be a real productivity saver.

I guess my only problem with this is that if this became standard, some git commit comment tyrant will start getting tyranical over the use of these particular symbols. Usually they have their own secret ones that you can get in trouble for not using.

In the end, you should stress less over this. But, find a friendly way of communicating with each other. In the end, there may be some process outside of git that should be considered for identifying the purpose of code changes.

I am certain, however, that Linus Torvalds never intended Git to be a weapon to use against coworkers. In fact, he said he invented it because other code control systems were being used to fire people. So, we should consider his original purpose. I think that he originally intended to unseat the position of repository master, a position to which many psychopaths aspire.

Idea: Maybe there should be a scale having to do with importance. Something like, "REFACTORED" begs the question of "how much?" a lot. REFACTORED: moved three line function from module A to module B. OR like this: REFACTORED: rerouted the L.A. freeway system at 6:00 AM monday morning - no worries the basic inteface with car drives on road did not change. But, the first one might be a 0.5 and the other might be a 10, on a scale of 0 to 10.

Collapse
 
pterpmnta profile image
Pedro Pimienta M.

Good ideas.

Collapse
 
codewithbernard profile image
Bernard Bado

This is very helpful. Commit messages are a lot of time source of truth.

Collapse
 
graytotem profile image
Graytotem • Edited

Keyword "FIX:" used several times in article. Is it Ok?

Collapse
 
ashishxcode profile image
Ashish Patel

I have fixed that 😅

Collapse
 
sehgalspandan profile image
Spandan Sehgal

Amazing content, thanks for sharing.

Collapse
 
the_riz profile image
Rich Winter

Lately, I've been using emoji to categorize my messages. Though I leave it to you to pick which you would use for the keywords above..

👍🏼👌🏼✍️💅🌲🕸️🐛👾🎛️🪠🔧🔨⚒️🛠️⛏️🔗🚫🆕🆙🆗🚮⚕️🏁🎨🚛🚀

Collapse
 
derlin profile image
Lucy Linder • Edited

There are no strict rules, but there are conventions!

I am surprised not to see any reference to conventional-commits which is the actual specification behind this practice. The spec, however, defines lowercase types (feat VS FEAT).

There is also a bit more to it (footers, breaking changes).

For anyone interested, I strongly suggest to read the spec and the angular conventions directly!

Collapse
 
rcls profile image
OssiDev • Edited

Also known as "semantic commits". When I started with this there were only feat, fix, doc and test. Later refactor. Now it seems these are growing every year.

Collapse
 
tlylt profile image
Liu Yongliang

conventional-commits is definitely the more popular/standard way to do this, especially useful for (auto) release management :)

Collapse
 
flimtix profile image
Flimtix

I like this schematic naming! Your article sums it up perfectly. 👍
Personally, though, I use emojis instead of prefixes because they stand out more.

Collapse
 
ashishxcode profile image
Ashish Patel

Yeah not doubt in that, but I feel it's about the preference

Collapse
 
po0q profile image
pO0q 🦄

Simple but efficient technique! Congrats.

Although, I would add one advice that I find critical:

Choose a naming convention and stick with it. It's important teammates use the same pattern. Best way to ensure that it pair programming with new members, but you can also document it.

Collapse
 
derlin profile image
Lucy Linder

Or simply use an existing convention, like conventional-commits which is actually the spec this article sums up 😉

Collapse
 
husseinkizz profile image
Hussein Kizz

I installed it but I like commiting from terminal, I don't think it was applicable then!

Thread Thread
 
derlin profile image
Lucy Linder

What do you mean install? This is just a convention you can decide to follow, nothing to install.

There are many tools built around the convention, yes, but you don't have to use them. I also commit from the command-line, the idea is just to follow the convention when writing the commit message (like shown in this article).

Thread Thread
 
husseinkizz profile image
Hussein Kizz

Yes I like the article and I will be following it on wards, perhaps to make it reachable I will create a Convention file in project to remind me until I can do it without reference. But up there I was responding to the conventional commits extension suggestion. Anyway thanks!

Collapse
 
ashishxcode profile image
Ashish Patel

Thanks will have a read 🙌

Collapse
 
po0q profile image
pO0q 🦄

not all organizations will follow that framework.

Collapse
 
jwp profile image
John Peters

Crazy simple. Good... thanks...

Collapse
 
ashishxcode profile image
Ashish Patel

I hoped it help you 😌

Some comments have been hidden by the post's author - find out more