Writing efficient commit messages; software projects, and Utopian
11 comments
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!
Comments