Reading commit messages is a great way to understand software evolution without reading all the code.
I use the following rule:
- start with an action verb: Add, Fix, Remove, Update, Refactore...
- include the concerned domain (if != code): test, documentation, config, scripts...
- a description to explain the "Why?" or "How?"
- and a reference to ticket or bug
- Fix tests for Linux platform: filesystem was hardcoded - #123
- Add configuration: support article pagination - #345
- Refactore customer subscription service to improve performance - #898
And you, do you use any rules to write better commit message in your company or open source project ?