I was talking with Adam Cogan this evening over the use of Source Control, and more specifically people who don’t check in code at the end of each day. This is a discussion I’ve had with a number of people and there are definitely some differing opinions on whether companies should have a “you must check your code in at the end of the day” policy. I’m a firm believer that this is for the most part a good idea, however it can often conflict with another policy that I’m in stronger support of: “you should never check in code that will break the build”. Clearly if you haven’t finished something at the end of the day you might not have code that compiles, ergo you shouldn’t check it in.
This dilemma is dealt with when you use TFS as your source repository because you can shelve changesets (there are other source repositories that have similar functionality). Basically this is like a temporary check in of your changes. It means that not only is your code backed up (in case you computer blows up), it also means that someone else can check out your changes and continue to work on them (ie in case you get hit by a bus).
So, with this in mind, here are a couple of check in rules (applicable to teams using TFS):
- You should never check in code that breaks the build – if you do, then you should stay behind and fix it before you down that first beer!
- At the end of the day you should not have any code checked out – it should either be checked in or shelved.