We use Git (Gitlab) and git-flow. The master branch is protected. The new code can only be submitted to master via a merge request. The Project owners duty is to check the code for smells and issues. Additionally, we use code review tool and code review process.
I think Gerrit is the most used review tool for Git repositories gerritcodereview.com We use github.com/ooyala/barkeep because we use Gitlab, and both (Gitlab & Barkeep) are written in Ruby.
Our process is simple. Unless a full-time code reviewer is hired (it never will be) we have a minimum of 5 reviews per coder per month. 5 is usually to less to significantly increase code quality and share knowledge. But 5 is good for avoiding endless discussions if coders are hired for coding or for doing reviews. People sometimes simply do not accept advice or blame from other peoples who may not have the same job title.
In projects where no Linting tool exists, or the project owner avoids to use one (limited knowledge, limited skills, limited mindset) we try to execute some spotting tasks:
And some common spotting tasks for all kind of projects:
If someone spots and issue, comment on it. The discussion may begin or gets ignored by the whole team (lack of time, limited ..., and sometimes political decision).
In case of the spotters comment gets accepted as an issue, an action is discussed. This can simply be a fix regarding the spotted issue type. Or a new refactoring task is created. With each refactoring task, we also agree to review the refactored code. That is when knowledge gets shared amongst the coders.
I wish we could do better and accept knowledge more quickly but we are all just humans after all.