Guidelines for Commit Messages

Those are only recommended guidelines and maintainers can feel free to adopt other guidelines.

Example

tag: Short explanation of the commit

Longer explanation explaining exactly what's changed, whether any
external or private interfaces changed, what bugs were fixed (with bug
tracker reference if applicable) and so forth. Be concise but not too brief.

Details

• The commit message is mainly for the other people, so they should be able to understand it now and six months later.

• Always add a brief description of the commit to the first line of the commit and terminate by two newlines (it will work without the second newline, but that is not nice for the interfaces).

• First line (the brief description) must only be one sentence and should start with a capital letter unless it starts with a lowercase symbol or identifier. Don't use a trailing period either. Don't exceed 72 characters.
• You can prefix the first line with one tag, to make it easier to know to which part of the module the commit applies. For example, a commit with "fish: Make it work with newer fortune" in the gnome-panel module clearly applies to the fish applet.
• The main description (the body) is normal prose and should use normal punctuation and capital letters where appropriate. Normally, for patches sent to a mailing list, the body is copied from there. This main description can be empty if the change is self-explanatory (eg: "Add DOAP file").

• When committing code on behalf of others use the --author option, e.g. git commit -a --author "Joe Coder <joe@coder.org>".

Linking to bugs

This is not part of the guidelines yet.

It makes sense to have a consistent way to refer to bugs in commit messages. There are several proposals so far:

• full link. Eg: http://bugzilla.gnome.org/show_bug.cgi?id=12345

• full text. Eg: GNOME Bug #12345.
• short text. Eg: gnome#12345, or bgo#12345. (in this case, bgo means bugzilla.gnome.org, rh means bugzilla.redhat.com, bnc means bugzilla.novell.com, lp means launchpad.net, etc.)

When a commit closes a bug, the commit message can contain this information in a parsable way. For example, with the short text proposal: "Closes: bgo#12345".