For the last couple of months, I’ve been leading an adoption effort at work to migrate developers away from our current version control system over to Microsoft’s Team Foundation Server.  During this time, I’ve been approached with a number of questions regarding best practices around source control usage, causing me to brush up on my own level of knowledge on the subject.

Recently, I was asked the following question:  When should I check in source code that I’m working on? At first, this seemed like a trivial question. But, since I didn’t have a good immediate response at the time, I figured it can’t be all that trivial.

So, upon further reflection – and consultation with several fellow developers – I’ve compiled the following list to be good situations in which committing changes to source control is a good idea.

You should check in files…

• When the project is first created
• When a new feature has been written (such as implementing a class, a method or a “slice” of functionality – from the GUI down through data access layer)
• Before refactoring or re-designing a component (so that there is something to compare with, or roll back to)
• When a bug has been fixed.

In what other situations would it make sense to check in files to source control?