One change at a time

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


The Xebia Essentials Cards

This page is part of the Xebia Essentials, a pack of flash cards about Software Development Done Right. You can get your own deck of Essentials cards in the Xebia store (sold out).

Buy Now