DEV Community

Cover image for A Beginner’s Guide to Git — How to Write a Good Commit Message
Gaël Thomas for HereWeCode

Posted on • Updated on • Originally published at herewecode.io

A Beginner’s Guide to Git — How to Write a Good Commit Message

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 historyGit 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 exampleBad 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.

Auto-generated Git changelogExample 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"
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
mcrmonkey profile image
ant Kenworthy

chris.beams.io/posts/git-commit/ details good practices for commit messages

From the above post these 7 rules stand out:

  • Separate subject from body with a blank line
  • Limit the subject line to 50 characters
  • Capitalize the subject line
  • Do not end the subject line with a period
  • Use the imperative mood in the subject line
  • Wrap the body at 72 characters
  • Use the body to explain what and why vs. how
Collapse
 
gaelgthomas profile image
Gaël Thomas • Edited

This post is an excellent resource to complete mine! Thank you for sharing it!

Collapse
 
motionblur profile image
motionblur

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.

Collapse
 
baharajr profile image
Bennett(he/him)

I use git commit without -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

Collapse
 
gaelgthomas profile image
Gaël Thomas

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! 😃

Collapse
 
baharajr profile image
Bennett(he/him)

Yours was well documented and fits so well for beginners. Thank you for taking your time on it.

Collapse
 
r0272mrz profile image
Sam • Edited

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.

Collapse
 
gaelgthomas profile image
Gaël Thomas

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! 😊

Collapse
 
t3h2mas profile image
Thomas Noe • Edited

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 -v to be able to see the code the message I'm writing references.

Collapse
 
gaelgthomas profile image
Gaël Thomas • Edited

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.

Collapse
 
tamouse profile image
Tamara Temple

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

Collapse
 
gaelgthomas profile image
Gaël Thomas • Edited

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! 😉

Collapse
 
llcamara profile image
LLCamara

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.

Collapse
 
gaelgthomas profile image
Gaël Thomas • Edited

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.

Collapse
 
llcamara profile image
LLCamara

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 :)

Thread Thread
 
gaelgthomas profile image
Gaël Thomas • Edited

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! 😀

Collapse
 
pinotattari profile image
Riccardo Bernardini

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.

Collapse
 
mattmoranjava profile image
Matt Moran

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.

Collapse
 
koffisani profile image
Koffi Sani

Some commit messages are just horrible.
Devs must keep following such guidelines to encourage collaboration

Collapse
 
gaelgthomas profile image
Gaël Thomas

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.

Collapse
 
dmahely profile image
Doaa Mahely

You're just gonna mention it and not link to the account?! 😜

Thread Thread
 
gaelgthomas profile image
Gaël Thomas

Of course, I will share it!! 😁
-> twitter.com/gitlost

I think I should add it to the article 😂👌

Collapse
 
gaelgthomas profile image
Gaël Thomas

So happy it helps you! Thank you for your comment! 🙏