One thing you could try is using a JetBrains IDE. They can do side-by-side diffs, static analysis in the diff view, you can edit directly from the diff viewer and of course you get full navigation and comprehension tools. When I left Google I spent some time trying to use GitHub's code review tools, but they are extremely basic. In recent years I found that with a custom git workflow I could use the IDE as a code review tool and it worked much better than any web based thing.
The trick is to use git commits as the review comments. As in, you actually add // FIXME comments inline on someone else's branch. They then add another commit on top to remove them. Once you're done, you can either squash and merge or just merge. This is nice because it avoids "nit" comments. If you dislike a name someone picked, you just go change it directly yourself and avoid a round-trip, so it reduces exhaustion and grants a notion of ownership to the reviewer.
If you need discussion that isn't going to result in code changes (about design for instance) you do it on the relevant ticket. This also has the advantage that managers who stay away from code review tools still feel like they understand progress.
It helps to use a specific way of working with git to do this, and to have it integrated into your other tools. I use gitolite combined with YouTrack and TeamCity to implement this workflow, along with a kernel-like ownership tree, but it works well enough at least in a small team (I never got to try it in a big team).
The trick is to use git commits as the review comments. As in, you actually add // FIXME comments inline on someone else's branch. They then add another commit on top to remove them. Once you're done, you can either squash and merge or just merge. This is nice because it avoids "nit" comments. If you dislike a name someone picked, you just go change it directly yourself and avoid a round-trip, so it reduces exhaustion and grants a notion of ownership to the reviewer.
If you need discussion that isn't going to result in code changes (about design for instance) you do it on the relevant ticket. This also has the advantage that managers who stay away from code review tools still feel like they understand progress.
It helps to use a specific way of working with git to do this, and to have it integrated into your other tools. I use gitolite combined with YouTrack and TeamCity to implement this workflow, along with a kernel-like ownership tree, but it works well enough at least in a small team (I never got to try it in a big team).