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
Top comments (32)
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!
conventional-commits is definitely the more popular/standard way to do this, especially useful for (auto) release management :)
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.
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.
Or simply use an existing convention, like conventional-commits which is actually the spec this article sums up 😉
Thanks will have a read 🙌
not all organizations will follow that framework.
I installed it but I like commiting from terminal, I don't think it was applicable then!
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).
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!
Just want to make sure, is it “ REACTOR” or “REFACTOR”?
Thanks, Will fix it
FIX: refactor
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..
👍🏼👌🏼✍️💅🌲🕸️🐛👾🎛️🪠🔧🔨⚒️🛠️⛏️🔗🚫🆕🆙🆗🚮⚕️🏁🎨🚛🚀
This is very helpful. Commit messages are a lot of time source of truth.
Crazy simple. Good... thanks...
I hoped it help you 😌
Lorddddd!!!!!
haha keyboard go brrrrr
Haha 😅
Do share this blog with your team
Good ideas.
Amazing content, thanks for sharing.
I like this schematic naming! Your article sums it up perfectly. 👍
Personally, though, I use emojis instead of prefixes because they stand out more.
Yeah not doubt in that, but I feel it's about the preference
I now use the gitmoji extension in vs code
Keyword "FIX:" used several times in article. Is it Ok?
I have fixed that 😅
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.:
(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.
can you share your commission naming method with emoji
Thank you
FEAT: 🚀
FIX: 🛠️
STYLE: 💄
REFACTOR: 🔧
TEST: 🧪
CHORE: 🧹
PERF: 🏎️
CI: 🚦
BUILD: 🏗️
Than you very much 🫡
Some comments have been hidden by the post's author - find out more