An often-posed question is when you should commit your changes.  Some people prefer to commit every night before they go to home.  Some people commit when they feel like it and remember.  However, probably the best way to commit is to make the commit when you have finished a feature.

A feature could be a new [JSP] page, a new UI component, or whatever - something that adds to the functionality of the system.

Commiting one feature at a time is a good thing because it keeps your own ''desk'' organised.  The risk of [breaking the build|DontBreakTheBuild] is also less.  [Writing good ChangeLog entries] is also easier.

__Commit a feature to keep the code organised.__


!Fixing bugs.

If you are working on a feature and someone comes in with an important bug, it's probably a good idea to check out a fresh copy from the repository, fix the bug, then commit that tree back to the repository and return to your original tree. This so that you wouldn't accidentally commit the changes you've already made to your usual tree for that new feature.


!Reformatting code.

Sometimes you need to reformat the code (say, because someone has been [using tabs instead of spaces|WhyTabsAreEvil]).  Commiting this file into the repository will cause lots of apparent changes, since most [version control systems] function on a per-line basis.

However, if you make any other additional changes (such as fixing bugs), the changes you made will be hidden by the fact that your line has now spaces instead of tabs when you take a "cvs diff", making it impossible for someone to figure out what happened.

__When you reformat code, commit the reformatted version before you make any other changes.__