Protection modes control how actively Code Reviews scans your repository and reviews your pull requests. They're the setting that decides whether Code Reviews works quietly in the background, or actively blocks non-compliant code from reaching your protected branches.
This guide covers what each mode does, how to set them up, and how to pair them with a quality gate in your version control system (VCS) so non-compliant pull requests (PRs) can't be promoted.
What protection modes do
Every Code Reviews project scans your repository against the policies you've configured. Protection modes decide what happens with the results of that scan: whether it's a passive audit, a helpful suggestion, or a hard block on the PR.
Getting this right matters as it determines whether Code Reviews can actually stop bad code from merging, or just reports on it after the fact.
Setting up protection modes
From the Code Reviews homepage, select the project you want to configure.
Go to
Settings, thenProtection.
Review the current mode and choose the one that fits your team.
Save your changes.
That's the entire setup in the UI. The mode takes effect immediately for new pushes and pull requests on the repository. This will automatically set up the webhook, so scans run automatically from then on.
The five protection modes
Mode | What it does | Best for |
| All scans are manual. Nothing is triggered automatically. | Teams not ready to standardize their development process yet. |
| Scans code whenever developers push to selected branches, without commenting on pull requests. | Long-term audits, or highly standardized branching strategies where you want visibility on specific branches without disrupting developers. |
| Reviews every pull request and suggest fixes with a non-blocking comment. It doesn't block PR promotions. | Teams new to Code Reviews, or teams that want feedback without enforcement. |
| Reviews every pull request and requests changes for issues introduced by the PR and/or detected by the Code Reviews status checks. It can act as a blocker for PR promotions if combined with branch protection rules in your VCS. | Teams that use pull requests extensively and want all new work to be compliant, without getting stuck fixing historic technical debt. |
| Reviews every pull request and requests changes for both new and pre-existing issues. Developers must fix legacy issues in any file they touch. | New projects, or teams that want the codebase fully compliant at all times. |
A few things worth knowing about how these behave under the hood:
Protect what's newandFull complianceare the only modes that generate a status check, the mechanism your VCS actually uses to block a merge.Protect what's newuses a reference date (legacy code date), so only issues introduced after that date count against the PR. This is what keeps legacy technical debt from blocking new work.Full compliancescans the whole file, so if you touch a file with pre-existing issues, you need to fix them, even if you didn't write them.
If you're rolling Code Reviews out to a team for the first time, start with Make suggestions or Observe discreetly to build confidence in the results, then move to Protect what's new once the team's comfortable acting on the feedback.
Using branch protection to stop non-compliant PRs from being promoted
Choosing a protection mode is only half the picture. On its own, Code Reviews will scan and comment on a pull request, but your VCS still needs to be told to actually block the merge if that scan fails.
This is where a quality gate, also known as a branch protection rule, comes in. It's a rule you configure directly in your VCS (GitHub, GitLab, Bitbucket, or Azure DevOps) that requires the Code Reviews status check to pass before a PR can merge into a protected branch.
Without a quality gate configured, Code Reviews can flag issues, but nothing stops a developer from merging anyway.
How it fits together
A developer opens a PR into a protected branch.
Code Reviews scans the PR and posts a status check with the result.
Your VCS's branch protection rule checks whether that status check passed.
If it hasn't passed, the merge (or, in a Gearset Pipeline, the promotion) is blocked until the issues are fixed.
If you're using Code Reviews as part of a Gearset Pipeline, this same mechanism prevents a pull request from being promoted between environments. A PR that fails a required status check on a tracked branch simply won't be eligible for promotion, and you'll be able to open the scan report, see the violations, and use FixBot to remediate what it can before raising a new PR to clear the gate.
Setting up a quality gate
The exact steps depend on your VCS. Gearset has a dedicated guide for each: