I generally commit in the following cases:
- I am switching to work on another document, especially one which is part of a different project.
- I am finishing for the day, taking a break or may be changing computers.
- I am about to run a system update on my laptop (which runs Arch and is therefore theoretically more vulnerable to unexpected breakage although that doesn't seem true in practice).
- I am stuck.
- I find myself worrying about changing things in case I lose them and change my mind.
- I want to send a copy of my current work to somebody else.
- I am about to print a copy and the document itself includes mark-up noting the revision information.
- I want to clean up files I no longer need, including generated files or old stuff. (This is in case I accidentally
rm my current work.)
- I want to move, rename, split or copy files.
- I'm about to try something which could go really wrong (especially with graphics) and I want a known-good point to revert to.
My commit messages leave a great deal to be desired, though, and I'd love to know how to make these more useful.
Revision control makes my code cleaner. I still tend to initially comment stuff out but every now and again I go through and delete to reduce clutter. I know the information is in the repo so I don't really need to put up with the mess.
Branching and tagging are starting to change my workflow but I have probably not yet figured out how to maximise their usefulness.
One of my projects takes a really long time to commit or update and that is quite annoying. (It is worse on my laptop for some reason.)
I have been greatly relieved to discover how easy it is to go back and reinstate earlier versions of bits of a document when I realise that I really ought not to have changed X to Y because Y is clearly more misguided than X!
I'm not sure this is a very helpful answer...