When you are working on a legacy codebase, sometimes you may want to understand the logic before you actually make changes. (Michael Feathers says legacy code as "code without unit tests". He describes lots of techniques to work with legacy code in his book Working Effectively with Legacy Code. There are bad unit tests also but that is a separate issue.
Exploratory Refactoring is an act of applying a series of refactorings to legacy codebase just to understand what the code does. During this exercise you'll check-out some of the code files but you'll not commit it. Once you understand the internal logic you'll throwaway all of the changes you made by roll-backing all the check-outs. Once you got the big picture of what changes you need to do and where to do etc. then you'll start actual refactoring and make code changes.
The kind of exploratory refactorings are like Extract Method, Decomposing Conditionals, Rename Method, Rename Variable, Introduce Explaining Variable etc. Some times its just code formatting like indentation, adjusting the number of blank lines and grouping the code fragments. During this you just want to make the parts of the code as apparent as possible.
During this phase you'll also get an idea of how clean and smelly the codebase is and how complex or easy the logic is, what is the intrinsic structure of the code, reveal the intensions of the author, which classes and functions hold what functional area of the application, and even get an glimpse of the environment like the coding and naming styles and standards followed. Overall you'll know the quality of codebase also.
You really don't have to be very careful in applying the refactorings because it is throwaway changes. The closer you get to real-life refactoring, the more you can learn from it. You will get to see some unexpected inter-dependencies, which can influence your real refactoring later on.
Keep refactoring! And develop with pleasure!