We use a standard GitHub process with a standard branching model (master and feature branches) for reviews. We require that each change is a separate PR and unl

We use a standard GitHub process with a standard branching model (master and feature branches) for reviews. We require that each change is a separate PR and unless it's an emergency we require that each change is reviewed before committing. We tried dedicated tools for reviews but found them too much of an overhead. Unlike some places with strict procedural requirements (e.g. Google with it's OWNERS and readability process) we depend on an honour system which given our size (~30 devs) seems to work rather well. We assume that doing code reviews is an important - if not the most important - thing in a dev's life so we spare no effort in order for the code to be reviewed properly while also not blocking others' work. However, we heavily rely on tools to ensure that human reviewers spend their time on things automated review can't figure out. These are generally linters and code smells detectors (e.g. reek in Ruby) which run on CI (Codeship). We use these helper tools to push statuses to GitHub and we block merging branches on CI passing so if tests are failing - which might even be just for a stylistic issue - human code review process would not even start. We also use a hosted code quality analyser (codebeat - which is our own product) to track quality over time, keep everyone on the same page and help devs and reviewers focus on the right things. Overall what we found out is that code review is a learning process and very thorough reviews for new devs help them ramp up very quickly so that subsequent PRs require less and less attention.