Are there any rules of thumb or guidelines for how to write the changes message of version control systems?
An obvious answer may seem a brief description of the most important changes but in reality it is not always easy to select the most important changes and describe the relevant aspects of these changes briefly, especially in early stages of development when large chunks of code are being added.
it is not always easy to select the most important changes and describe the relevant aspects of these changes
It can be, if you keep your commits tight and focus on a specific change, as in "logically separate changeset": see "git commit frequency".
(And don't forget to wrap your comments properly: depending on other processing tools (emails, patch tools), the length of comment line can matter.
It depends on the goals of the project. We use Git and require four fields:
Brief Summary (one line subject of commit)
Related Tickets (used to integrate with Trac)
Detailed Report
Future Work Required
Our Git repositories have hooks that require the commit message form to be filled out correctly otherwise the server rejects the commits.
This way, people can see the summary line and get a good idea of what happened while the detailed report is available for anything tricky and the future work allows everybody to see what issues still exist.
I find it helpful to start commit messages with past-tense verbs: Refactored the X class, Added feature Y, Rolled back previous change, etc. This consistant style makes it easy to read through message logs when you come to look back at them later.
It's also useful to add a reference to the tracking ID in your bug tracking system, so you can investigate the full background to the change in future if necessary.
