- integrate before you check in to minimize the possibility of breaking the build. A frequent mistake is forgetting to add new files, so having a second workspace just for verifying changelists might help you catch the files you need to add for the build to succeed.
- minimize the number of files which go into each change list. Small changes are easier to understand, merge, and roll back if necessary. Also, each change list should correspond to a single item in the issue tracking system. You are using an issue tracking system, right?
- diff each file to make sure you're checking in only what you want to. You don't want that test code you added while debugging creeping into the source. Give yourself a gold star if your process includes code review before new code is added to the baseline.
- provide check-in comments which actually describe the change(s). That is, instead of a useless comment like "Fixed crash", provide a comment like "Fixed the Foobar ctor to check the spizzbot pointer."
- if the check-in is a bug fix, make sure you check in a test. You are using a unit test framework, right?
- do not leave your workplace right after you check in code. Hang around long enough to verify you haven't broken the build and all the tests pass.
In fact, this is exactly what your build server or continuous integration server should be doing: no build should implicitly depend on artifacts from another build.
