Gerrit/Commit message guidelines


 * Please note this article is also transcluded at Git/Workflow.

Commit message guidelines
Crafting the commit message is a very important step of your development work. The message is usually the first thing other developers will see, and the first line in a Git commit-msg has a special meaning. It is considered the "Title" or "Subject" of the commit. Many interfaces use this title to represent the commit. For example:
 * Subject of e-mail notifications
 * 's "oneline" mode
 * Gerrit interface (dashboard, search results, title)
 * Git revert (cites the commit title)
 * Various Git GUI clients (use first ~ 65 chars as title, rest separated by empty lines as collapsible body)

Aside from the tools that use it is also considered useful to the reviewer to have a concise headline identifying the commit. If you can't summarize the commit in a short line, perhaps it is still in a too early phase or maybe it contains too many different things that should be broken up into different commits.

After the headline comes the body of the commit message. It should be separated from the headline with an empty line. In here put a detailed message fully explaining your patch, what you did, your design choice, possible culprit to look at, any research you have done. Bytes are cheap, so just write! Generally the message body should wrap between 70-100 characters.

A few other guidelines for the content of the headline or the body:
 * If your change is fixing a bug, put that bug's number at the very beginning of the headline in parentheses:
 * Whenever you refer to another commit, using either the git-commit SHA1 of the merged commit or the Gerrit Change-Id of the change set in Gerrit. Do not refer to git commit hashes of changes that have not been merged yet, in that case you should use the Gerrit Change-Id.

Good example :



See also:
 * http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
 * Git/Introduction
 * http://datamapper.org/using-git.html