Recently (I'm talking about the last three or four months or so), I relied on restoring an older version from a backup, at least for some parts of the project. The project is, of course, ZPE Programming Environment. This is because the new features added unintentionally caused issues with previously added features. Much to my disappointment, this meant rolling back several versions of the code to mitigate the problems brought by the new changes.
My commit messages helped a lot here but were not perfect. The messages often describe fixes or new features being added but do not detail precisely how I do this. That's because the ZPE Programming Environment core is closed-source, and I do not want to share all the new things in full detail to everyone (particularly when it could affect security).
Take this commit:
Added a fix that seems to have fixed bug #35 ("Fix excess bracketed calls")
They are far more helpful because I can refer to the bug in more detail. This led to the ZPE Tracker, which is designed to identify and describe bugs and features brought to ZPE and allows commit messages, which could be done just before heading to work, to be much less detailed and just linked to the bug number.
Anyway, commit messages are designed for several reasons, but one of the main reasons is that if a program needs to roll back to a previous version, finding that version can be done much more straightforwardly. ZPE is multifaceted in that I record commit messages, update the changelog, and maintain a list of bugs and features on the Tracker.
In general, from working in the industry and working on my projects such as BalfBar, DASH etc, commit messages must be incredibly detailed. They are designed to ensure that other developers can pick up the code and figure out exactly what happened in the last commit and for team members to see exactly what a developer did on a project. Messages, therefore, must be incredibly clear.
