Writing efficient commit messages; software projects, and Utopian
At Utopian, we have a different kind of metrics to score a contribution. One of them is about commit messages. And I generally have to score low or average on that question.
Why developers should write good commit messages?
- It will help other developers to understand what's happened inside the change set for each commit.
- It will help to speed up the code reviewing process. (This also applies to Utopian moderator reviews.)
- It will help internal teams (generally project management side.) to create changelogs, announcements on new iterations. Everyone can read and understand a text, but, not everyone can read and understand the change set in the source code.
What is a good commit message, anyway?
The creator of GIT and Linux, Linus Torvalds describes a good commit message like this:
Header line: explain the commit in one line (use the imperative)
Body of commit message is a few lines of text, explaining things
in more detail, possibly giving some background about the issue
being fixed, etc etc.
The body of the commit message can be several paragraphs, and
please do proper word-wrap and keep columns shorter than about
74 characters or so. That way "git log" will show things
nicely even when it's indented.
Make sure you explain your solution and why you're doing what you're
doing, as opposed to describing what you're doing. Reviewers and your
future self can read the patch, but might not understand why a
particular solution was implemented.
Reported-by: whoever-reported-it
Signed-off-by: Your Name <[email protected]>
where that header line really should be meaningful, and really should be
just one line. That header line is what is shown by tools like gitk and
shortlog, and should summarize the change in one readable line of text,
independently of the longer explanation. Please use verbs in the
imperative in the commit message, as in "Fix bug that...", "Add
file/feature ...", or "Make Subsurface..."
At the end of the day, it's not very complicated. Just make sure you have a simple one-liner header, and a descriptive summary about the changes.
Also, using imperative mood is something I have been wanting to see in commit messages. It's also mentioned git's original repository
[[imperative-mood]]
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behavior.
Some bad examples
Oh, there are so many of them. A search query with damn on commit messages at Github, results with 642,505 commits. Unbelievable, right?
Utopian reviews
We don't want to bother developers with details, however, we want to see git logs clean, understandable. That's why we have a separated question about this on our review questionnaire.
If you care about this, not only you will get better review scores, you will also have better git logs which will help other contributors to work on your project.
Happy coding!
It's an honor to moderate the first #iamutopian post. We don't really have an appropriate scoring format for these posts, of course, as they are a new and unique thing we're doing. Therefore, the score won't be reflective of the post's quality.
This is a very useful post, and one that I hope future contributors to your category will read and refer to.
I do have a couple of comments, because I always have a couple of comments.
On the style and grammar side, the post is generally quite good, but there are small issues.
For instance, "we have different kind of metrics" should be "we have a different kind of metrics"
"speed-up code reviewing process" should be "speed up the code reviewing process." Note that I removed the hyphen from "speed up" as well.
On the content side, I would have loved to have seen your own explanation of what makes a good commit message, not the one Linus wrote. I would have also liked "some bad examples" to include some actual bad examples.
Thank you for your contribution and for being the first to brave the waters of #iamutopian.
Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.
To view those questions and the relevant answers related to your post, click here.
Need help? Write a ticket on https://support.utopian.io/.
Chat with us on Discord.
[utopian-moderator]
Thank you for the review and great feedback.
Thank you for your review, @didic!
So far this week you've reviewed 15 contributions. Keep up the good work!
i hpe in the chage life .........
Yeah usually for projects I usually prefer commitlint to add in git precommit hook so that commit cannot be made without proper commit convention.
commitlint looks awesome.
Thanks for this!
I was always under the impression that commit messages needed to be short and to the point. However, now that you shared what Linus said about them I won't be afraid to write more after the one line at the start.
<3 J. R.
I would also add, that it's good to have task/issue number (if it exists), first in the commit header, like
ASD-123 Fix main window not being displayed. That way you can quickly see which commits are related to each other in git log.Good point. We practice this also in our workflow at the company.
Thanks for the clear write-up. I have something that I would LOVE to discuss with you about Utopian and git commits. Maybe we could meet up on #VIPO ?
Thanks so much for the enlightenment. Honestly, I would say I'm one of those that write bad commit messages because I never knew the usefulness until I joined utopian which I couldn't escape it and I improved a bit.
Please, I would still like to know more on writing good commit messages because the samples you gave here aren't clear enough for me. Thanks.