Writing a commit message

A good commit message should have two basic parts; a subject, and a description (if required). The subject is always on the first line (and only the first line), and the description is always separated from the subject with a blank line.

<Subject: brief one-liner describing your changes>

<Description: if more detail is needed, then skip a line
and put it in the description. However, if you don't think
you need it, then a one-line commit message is OK>

Additionally:

• The subject line should be no longer than 72 characters. Lines in the description should be no longer than 80 characters.
• Always use imperative mood for commit messages, as if you are commanding the code to change its behaviour; instead of saying "I added a new feature" and "I fixed the bug", say "Add a new feature" and "Fix the bug".
• Make sure your commit message contains an accurate summary of your changes (for example, "Made some improvements" is a bad commit message). If you're finding it difficult to summarise your changes in one short commit message, then perhaps you should consider breaking the change up into multiple commits, within reason (i.e. no broken commits-- every commit should compile and be functional).

Some examples of bad commit messages (Using a fictional I2C library as an example):

I2C library fixes

update README

LIBRARY UPDATE COMMIT

fix for bug #334

various fixes for I2C library

Some examples of good commit messages (Using the same fictional I2C library):

I2C library: handle null pointer in i2c_getbytes()

Add documentation URLs to I2C library README file

Upgrade I2C library version number to 0.5

I2C.h: Remove unused value in i2c_controller struct