My guess is each phase is it's own branch, coming off of a shared main line.
Each phase has it's own set of goals to test, with the current phase being the main line branch that everything else pulls from.
In the week or two between phase 1 and 2, they will merge the code from the phase 2 branch down to the main line and make sure that nothing is conflicting with the changes they had made in the phase 2 branch already. the same will happen between 2 and 3, and 3 and 4.
This allows the them to split into software teams that handle each section of the game in their own branch without affecting the other developers. Branch merging is the time consuming part (we do this a lot in the software I support), especially when there are conflicts between files. I expect that's why they need a week or two between phases, to make sure the merges are performed correctly.
The main line branch is what the testers are playing on, and probably where the current phases changes are made. The developers working in the other branches can pull the latest code up to their branch from the main line branch and make sure the most current set of changes made during the current phase of testing are compatible with the things they're working on.
It sounds complicated but works pretty slick when properly implemented.
Edited, Mar 27th 2013 10:19am by Wint