Don't group many changes together into a single commit. Commit each logical change as a separate revision.

Keeping changes small and simple in individual commits makes many later things easier:

• small, atomic changes are easier to disapprove later.
• This makes it easier for others using pluck for CherryPicking only the changes they are interested in, because each can be referred to separately.
• If you separate bug fix commits from other development, it will help release management (especially if you commit them according to the DaggyFixes pattern).
• Doing frequent commits along a separate development line will also help when it comes time later to merge that development back with other work (as well as helping you go back to a previous state if some experimental changes didn't work out well). If you haven't done progressive propagates to keep the development branch in sync with the mainline during development, you can use the ZipperMerge pattern to recreate these small merges later.

If you find yourself making several parallel changes, consider using parallel workspaces, one for each change.

Using restrictions on the commit command (ie. mtn commit file_a file_b) to commit a small subset of the changes in your workspace. Check with diff to review what changes the restriction matches.