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@example.com> 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
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.