My team uses a Gerrit server for code review that runs on an AWS instance that the software mentors maintain. At competition, the students make test branches locally and merge to master after testing. They either push them to Gerrit at the end of the day or tether to a phone to push to the server. Since I was at university for the last few years, I was typically not at competition, so the students occasionally pushed patchsets to Gerrit for me to review remotely and catch potential issues (I was usually watching the regional that weekend online anyway). I either leave the comments in Gerrit or ping them directly on Slack.
We use Gerrit for code review because I like the rebase workflow better than the merge workflow of GitHub (and we enforce rebases through the admin interface). I cover more of how to do that stuff in the presentation at https://csweb.frc3512.com/ci/git02/. I still need to go through those and expand on the lecture notes.
To make the students self-sufficient at competition, I teach them how Git really works. I try to emphasize how Git is basically an application of graph theory, because having that deeper understanding has saved our butts a couple times at competition when my students start doing hairy things to the branches and history (my students are all comfortable using “git reset” to move around the reflog). The HTML intro slides I use are at https://csweb.frc3512.com/ci/git01/. There’s always a set of Git commands to fix the issue at hand, so recloning should never be needed. (This is nice: https://github.com/k88hudson/git-flight-rules/blob/master/README.md)
As far as branch hygeine, we keep master as the working version and give branches descriptive names and commit messages (no "Fixes " branch and also “Fixes the issue for real, I promise” with no indication as to which is the real “working” branch). A clean commit history also makes code review much easier. I despise merge commits for this reason; they are just noise (last I checked, Brad was tied for most commits in wpilibc/wpilibj if you include the huge number of merge commits). Just rebase against master since you’re doing that merging work either way and you get cleaner history with a rebase. Rebasing a PR on GitHub or a changeset on Gerrit is technically modifying public history, but we treat those branches as private so the author can rebase it to produce a branch that is easier to review.