I'm going to offer an answer that is orthogonal to your question by looking at a deeper question. The "work-flow" you seek may actually be irrelevant to the problem of (a) being effective with your students and (b) being efficient with your own time and effort. Hopefully, the answer here will be valuable to others who don't have quite the same context that you do. I'll focus on the small number of students and the long daily sessions, primarily. The answer will be less valuable for larger groups and/or shorter sessions, but some of it might be adapted.
tl;dr: Keep continuously aware of their progress, day to day, with short conferences. Restrict your evaluation to the most important issues as they evolve.
With only a few students and long sessions, there is really little reason to have to look at everything in detail, captured by GIT, or otherwise. This is one situation in which printouts sounds like a terrible idea also, though that is often the most efficient method of looking at student production.
You can both reduce your work and be more effective if you require some sort of teamwork, such as pairing. If you only have five projects to keep straight it is much easier than ten. You can, in long sessions, set aside say one hour in which each team consults with you for a few minutes on their current work and issues. They show you their current product and you give them advice. But if they are pairing, they will need less advice.
One concern you likely have is honesty. Looking at each student's (team's) work for a few minutes each day (or so) lessens the likelihood that you won't notice bad behavior.
One thing that will help you keep track of the students and keep them on track as well is to keep a running record of their progress. A Hipster PDA (discussed elsewhere on this site) is one way. A spread sheet is another. Decide before the course starts which low-level results/behaviors/activities are to be encouraged and valued and keep a record of these for each team, each day. A check mark is all that is needed for many things, though occasionally a written note (to them and/or to yourself) might be valuable. It is a continuing and cumulative process, not an all-or nothing evaluation at the end.
If students work in teams you can also keep yourself aware of each student's contributions to the team simply by listening to how they interact when you confer with the team. A quick notation on an index card captures your impressions for re-confirmation later.
If you need to give advice on code quality you don't need to look at it all at once, but can look at fragments (one class, one method) in a review and get a sense about whether they have it right or not. You won't catch every flaw, but you aren't guaranteed to catch everything in an overall review either. If several teams are going wrong in the same way you can alter your "lectures" to guide them back. If a single team/student is off the rails you can focus your efforts there, instead. None of this requires that you capture everything in a repository or even that you comprehensively review their work.
If design is one of your goals, you can focus your daily review on that, warning them the day before that you need to see designs, either on paper or otherwise.
Even if you don't want the students to work in pairs/teams, you can still use a different form of teamwork. You can, for example, set up a rotating peer review system in which each student briefly confers with another on each student's work. Each can give advice to the other. I suggest that the advice be written, say on index cards, with both student's names listed as well as the questions/advice/etc. You can quickly review these cards and can give credit to both the one receiving the advice (for responding appropriately) and the one giving it (for being a good colleague). You can use this instead of conferring with the students/groups yourself on some or all days. Students can teach each other and will if you give them the opportunity and encourage good behavior.
