You are a developer, and you started to use Git recently? If you are wondering what the best way to create a good commit message for your project is, then this article is made for you.
After a few weeks without writing new articles, I’m coming back today with the next part of one of my most searched posts on Google.
When I started to write, one year ago, I created an article on how to start and create your first repository with Git.
This article is appreciated by the community and helps many people each week. Thus, the next part of this series will be how to write a good commit message.
What is a good commit message?
As a short reminder, the commit message is the short text you left when you save your work on Git. This message has the specific goal of identifying your work.
Just by reading it, anyone will be able to clearly understand what you did in this part of your work.
A good commit example
Below, you can find an example of the last commits on Angular.js project on GitHub (a famous framework made by Google). As you can see, messages are clear, and we can better understand which work has been done in different parts.
For example, on July 24, 2019, “gkalpak” upgraded “SauceConnect” and switched to the last version of Safari (web browser).
Git commits history on Angular.js project on GitHub
Why is everyone not committing the same way?
Unfortunately, commits do not have a universal way to be written. Each project and each company define specific rules for their needs.
Don’t worry; you will often find similar ways of writing the message.
Although, I highly recommend you to read the rules before starting in a company or working on an open-source project.
I will give you more details on these guidelines later in this article.
Why is it essential to write your commit well
I created a shortlist of the advantages of using a good commit message.
- A better collaboration: If you are working in a company, on an open-source project, it’s essential to follow the rules for better cooperation. If you write something understandable, following the rules of the project, the other developers will be able to work more efficiently, and they will not be required to ask you questions about your work.
Note: If you are working on a personal project, I highly recommend you to follow specific rules. It will improve your productivity, and if you ask help from another developer, it will be easier for him to start working on your project.
- A better understanding: You need to create clear and understandable messages; it will help you and your collaborator to work on a project. Below, you can find an example of a git commit history with only unclear messages. As you can see, it’s difficult to understand what is made.
Bad git commits example from Jason McCreary
Note: If you want to have more example of bad commits and have fun at the same time, a Twitter account named "gitlost" is tweeting every day with the funny and unfiltered commits.
- BONUS - A changelog generation: I’ll tell you a small secret, if you write good messages, you will be able to generate a changelog directly from your commit messages. I share with you a few tools to do it: Github Changelog Generator, Git Chglog, Auto Changelog, and Conventional Changelog. Probably the next part of the series will be on this, if you want to be updated, you can follow me on Twitter. I post every update there.
Example of auto-generated Git changelog
How to write a commit message?
If you want to write a good commit message, you need to follow some rules. I created a checklist below. Every time you want to commit, take the time to refer to this list.
- Always check your grammar. It's never pleasant to read a message full of errors. To do this, I recommend you to use a grammar tool. If you are writing in English, you can use Grammarly, Reverso, or GrammarCheck. These tools are not perfect, but they will remove most of your errors.
- One commit, one change. Try to commit often. The ideal is to have each change in a different commit. It will be easier for you to go back to previous work.
- Be clear. When you are writing a commit, try to be as transparent as possible. I recommend you to use simple English to go straight to the point.
- Details what you did. Take the time to reread your code to write what you did. In the case you need to detail a lot, I recommend you to use the description part of the commit.
ADDITIONAL INFORMATION: I want to share with you more details on the 'git commit' command. If you are not using a git software, you should know that you can create detailed commit by typing this command:
$ git commit -m "Title" -m "Description"
It's the same as before, but with a second part for the description. So, "-m 'title' "is to write the short title of the commit, and "-m 'description' "is to write the description if you need to give more details.
- Use a git guideline. If you want to have a clear git commit history, I recommend you to follow a guideline. It's a guide of how to commit. In my case, I choose this simple one from Udacity. There are a lot of others; a few of them are Conventional Commits, and Angular Guideline. A commit guideline will help you to put an architecture to your commit. For example, put a tag to clarify what you did: "git commit -m fix: correctly delete all user information when the button delete account is triggered'".
Conclusion
I hope that you liked this guide on how to commit to Git! If you have any questions or feedback, feel free to ask.
If you have any other tips on how to make good commits, please let me know.
If you want more content like this, you can follow me on Twitter, where I tweet about web development, self-improvement, and my journey as a fullstack developer!
Top comments (23)
chris.beams.io/posts/git-commit/ details good practices for commit messages
From the above post these 7 rules stand out:
This post is an excellent resource to complete mine! Thank you for sharing it!
I've been encouraging my teams to use Chris' guideline for at least 5 years. It's great in practice and keeps the messaging unified.
I use
git commitwithout -m and it opens up my default editor (Vim),Then the first line defines the title
The second line will define an issue I am working on/fixing if any
The third line will have a well-written description of the commit
Thank you for sharing this. Indeed we can do that. I found the solution with the two "-m" more comfortable to explain. That said, yours is excellent for taking the time to edit the commit! 😃
Yours was well documented and fits so well for beginners. Thank you for taking your time on it.
I find that if it's difficult to describe a change in just the title/subject line (and stick to the character limit), then I am usually committing too much at once and should break it up into smaller commits.
Yes, it is! It's a great practice to do smaller commits.
As I recommend in my post, you can use the following command: "git commit -m 'put a title' -m 'put a description'".
With this, you can write a small title and add details in the description part of the commit.
Hope it helps you! 😊
Valuable for everyone (using git!)
I'm going to review these points before I start my day tomorrow. My coworkers may be thankful that I do.
(Side note) I'm a fan of using
git commit -vto be able to see the code the message I'm writing references.I'm glad it can help you! Thank you! 🙏
(Side note) I didn't know about "git commit -v"!! It's useful if you only use the terminal. I take note of it.
If you want to check your changes before committing, I highly recommend using a tool like Fork.
this is not just a thing for beginners; seems like most devs, all the way along the spectrum just do not care about this. i see so many empty message bodies on commits, with just the title like you showed, one word which says zero about what was done and why.
anyway, good article and thanks for letting me get that off my chest
So true.
At least, if the title is explicit, it's okay. If it's not, a body is useful.
I think it's a good reminder for most developers.
Thank you for your comment! 😉
I personally don't entirely agree with the statement: "Just by reading it, you will be able to remember what you did in this part of your work."
I always repeat that commit messages should be written not to yourself, but for others. A better philosophy would be: "Just by reading it, anyone will be able to clearly understand what you did in this part of your work."
The ability to remember yourself is a natural side-effect of a well-written commit message.
Hello @llcamara ,
You're right! This is what I wanted to mean, but I'm not a native English speaker, maybe it is the reason why I misspoke myself.
When I wrote this guide, it was with the idea of creating a good commit message to mainly improve the collaboration and the productivity (ref: "Why is it essential to write your commit well").
Thank you for your feedback and the proposal!
I update this part of the article right now with your sentence.
Don't get me wrong, I really liked your article and I did understood your points about the importance of collaboration as it went on.
My comment was just a small improvement suggestion, that further reinforces this idea. I'm happy if it helps somehow :)
Don't worry, I didn't take it wrong! 😊
I love receiving feedback from my readers; it's an excellent way to improve the quality of my article.
Anyway, I'm glad you liked the article! Thank you for your help! 😀
I did not know about the double "-m," neat!
I work mostly on personal project (but exported as open source, so I want to maintain a "presentable" look) and I have this habit: I keep two "reference" repositories on two different git providers (typically github and bitbucket). One repository is the official open source rep, the other one is for my own use. When I am working on a specific feature, I create a new branch that I associate with the private rep and use it to save the intermediate states with embarrassing comments like "saving a snapshot."
Whenever I reach a stable, publishable state, I squash the changes in the main branch and publish it on the public rep, this time with a meaningful comment.
If you specify a text editor in your git config, e.g.
editor = /usr/bin/vim
then you can write your commit messages in a more composed way.
Where I work we follow an in-house rule. The first line of the commit message cannot exceed 80 characters, and must begin with the relevant JIRA ticket reference, followed by a space & a pipe character - e.g.:
LRA-4628 | Fixed tests that were broken by front-end change
and then if it needs any further explanation you can put, after a blank line, a short paragraph on what was done. The ticket reference should give you all the info you need, but I find if there was something out of the ordinary found during the change I like to document it in the commit message too.
Some commit messages are just horrible.
Devs must keep following such guidelines to encourage collaboration
I agree with you! I follow some Twitter account about it. They share ugly commit messages, it’s funny, but at the same time, it’s sad for people working on the project 😂.
Guidelines are so important.
You're just gonna mention it and not link to the account?! 😜
Of course, I will share it!! 😁
-> twitter.com/gitlost
I think I should add it to the article 😂👌
So happy it helps you! Thank you for your comment! 🙏