A single commit should contain only changes related to a single user story or issue. For instance, don't mix formatting changes with bug fixes. In other words: A change should have only one reason to be reverted.
In case of problems it is very helpful to be able to blame just a few lines that were changed, instead of 20 files that contain everything from reformatting, refactoring log statements to changes in the transaction API.
All projects where source control is used.
- Apply changes one at a time, e.g. when you fix two issue tracker tickets in the same file, record the changes for both fixes as separate commits in version control.
- Separate code clean up from functional changes. So Don't combine formatting changes and semantic changes in a single commit.
- Check each changeset before you push it to the central repository, to see if it communicates your intention.
- Easier to inspect and review changes in SCM history.
- Enables cherry-picking of changes.
- Reduces hassle if a change needs to be reverted