The general rule is to keep check-ins small and check-in often. But sometimes the task requires large changes to the underlying framework. Then checking in before compeleting the task will break the project until you check in the finished work.
So what strategies do people use to reduce the risk of losing work, or deciding something you are doing is the wrong approach, then changing your mind after removing the code and trying another approach?
When I can, I'll check-in half done work commented out, or if it compiles and nothing is using new files I'll check them in. The larger the change the more likely I am to branch the project and then merge back when I have everything working again. Another option if the source control system allows is shelf sets, which are basically small branches. So when I finish for the day or come to a decision point, I'll shelve my changes, and then if something catastrophic happens, or I want to come back to that point, I can.