I think part of it depends on the tooling that you're using and what your review system supports. Assuming that these are all supported, I would generally: 1.

I think part of it depends on the tooling that you're using and what your review system supports. Assuming that these are all supported, I would generally: 1. Push very often, essentially every time I'm going to context switch or take a break 2. Iterate often, get things working, then clean them up, pushing at each step along the way 3. Interactive rebase to squash into meaningful stacked commits for review 4. Mark the change as ready for review by my team I have found stacked commits to be the best way to both perform and author reviews by a wide margin. It's so much easier to review 4 200 line semantic changes than a single 800 line change. You'll get better feedback from others, and thinking about development in this way can also lead to better results on its own.