In my experience, when possible, the commit messages should read as part of a spec, describing the implemented behavior (mostly imperative). Even when fixing a

In my experience, when possible, the commit messages should read as part of a spec, describing the implemented behavior (mostly imperative). Even when fixing a bug, the commit would state what the code is intended to do, just as its resp. test exercises. This way it's somewhat easier to follow the reasoning of the committed changes. Another detail is to prefix a subsystem affected, that's in case of modular or complex application. Also help focus the attention. My preference in general is to write single line messages (shorter ok, longer - ok too), unless it's something very non-trivial and source-code policy discourages lengthy comments.