什么时候Check In ?
好像不是什么问题，我记得我使用VSS6的时候，没有什么原则，随时都可以，想要备份一下代码就Check In一下。但是在 TFS中，Check In 是有原则的。
场景：
在Process Guide中，Check In涉及到的 Workstreams and Activities只有2个 ：
l Fix a Bug
l Implement a Development Task
这意味着，至于这两种情况下需要签入。也就是说，只有这2个过程设计到代码的修改。同时也意味着，任何需要对代码的修改都会产生这2个任务。
在初次的设计开发中，当然会产生 Development Task，在Change Request中，也是要产生一个Development Task的。而且，只有Development Task Test和Review都完成了才签入。
问题：
问题来了，如果Development Task还没有完成，另外一个Change Request也涉及到这个Development Task的代码怎么办呢？
我没有想到什么好的办法，但是没有好的办法也总要有个解决的办法，最终决定，把Development Task做一次签入在做Change Request的Development Task。
避免的方法：
把Development Task划分的粒度减小，这样问题发生的机率就会小。
保证只有Development Task Test和Review都完成了才签入的好处：
代码和Work item之间保持一致的关联，记录完整的一致修改轨迹，便于以后恢复，查证和修改等。