In our team we encourage checking in as often as possible. We check in when we have a something that works - even if only partially and with no visible deliverable. No code is checked in without a code review. We use Jetbrain's TeamCity with pre-tested commits and unit tests, so it is not possible to check in code that breaks the build or the tests (integration tests excluded). We have found that frequent check-ins encourages building code up in incremental blocks and unit tests. It also makes it much easier to refactor your own changes without affecting code that you are happy with (read: just recently checked in). Code reviews become less time-consuming when few files are checked more often (20+ file changes is also a mental strain when reviewing code).
E
Eskil Hauge
@Eskil Hauge