I think it's difficult to give advice on code review in isolation of the rest of your development process - code review is but one small piece in a good workflo

I think it's difficult to give advice on code review in isolation of the rest of your development process - code review is but one small piece in a good workflow. I'll describe what has worked best for me in the past. My team are all quite git-savvy, all unafraid of a bit of interactive rebase to craft a nice clean history on our feature branches. This means that we can all trust that reviewing a pull request commit-by-commit, reading the commit messages and inspecting the changeset to verify that it does indeed achieve what it says on the tin, will actually be worthwhile. Having said that, we also try to keep the pull requests as small as possible, so a good proportion of them only end up being a single commit anyway. We do this in part by throwing up what we call "skeleton pull requests", where we submit an interface or a placeholder API definition with hard-coded return values so that the design/shape of the work can be reviewed before the meat of the implementation begins. If we notice that we need to change the design during the implementation, we'll usually throw up a draft pull-request as early as possible and ask reviewers specific questions about the parts we're changing to get their thoughts.