Recommendations for writing a message about changes in version control systems?

Question

Are there any rules of thumb or guidelines for writing changes message version control systems?

The obvious answer may seem a brief description of the most important changes , but it’s actually not always easy to select the most important changes and briefly describe the relevant aspects of these changes, especially in the early stages of development when large pieces of code are added.

Answer 1

It depends on the objectives of the project. We use Git and require four fields:

Short summary (one line of the subject of fixation)

Associated tickets (used for integration with Trac)

Detailed report

Further work required

Our Git repositories have hooks that require the commit message form to be filled out correctly, otherwise the server will reject the commits.

Thus, people can see the final line and get an idea of ​​what happened when the detailed report is available for something complicated, and work in the future allows everyone to see what problems still exist.

Answer 2

it is not always easy to select the most important changes and describe the relevant aspects of these changes.

This can be if you keep your commits tight and focus on certain changes, as in a “logically separate set of changes”: see “ git commit frequency ”.
(And do not forget to properly cover your comments : depending on other processing tools (emails, patch tools) the length of the comment line may matter.

Answer 3

It’s useful for me to start committing messages with past tense verbs: Implement class X, Added function Y, Shift previous change, etc. This consistency style makes it easy to read message logs when you come to look back at them later.

It is also useful to add a link to the tracking identifier in your error tracking system so that you can investigate the full background for future changes if necessary.