When first starting with Code Reviews, it's important to understand the differences between Status checks and PR reviews. This document aims to clarifies the distinction between Git Status Checks and targeted Code Reviews PR Reviews, explaining the role of the Legacy Code Filter in managing technical debt and ensuring a consistent development workflow.
​

The feedback from Code Review[bots] takes a targeted approach. It analyzes only the files that have been changed in the current PR, highlighting issues specifically introduced by those changes while ignoring pre-existing problems. This method keeps feedback relevant to what was actually modified, avoiding legacy issues.

When using Code Reviews, you can configure status checks for the different policies applied to your projects, such as Intentional, Automated, Engaging, Resilient, Secure, Reliable, and Compliant. These status checks act as automated quality gates that must pass before a pull request can be merged.
​

Unlike basic code reviews that assess only the changes introduced in the current pull request, policy-based status checks evaluate all files included in the revision, regardless of whether the issues originated in the current pull request or a previous one. This approach helps ensure the overall health of the codebase rather than focusing solely on incremental changes.
​

As a result, even if a pull request modifies only a small number of lines, the status check will fail if it detects any existing issues within the affected revision. Each revision is treated as a single unit, making the outcome effectively all-or-nothing: any violation new or inherited causes the status check to fail.
​

In addition to policy-based checks, you can also use the Code Reviews Approval status check. This check differs from the others in that it evaluates only the items introduced by the pull request. Rather than relying on reviewer counts or identities, it enforces merge readiness based on policy evaluation of the pull request’s changes.

Many teams depend on minimum reviewer requirements to control merges, but these rules can be inconsistent and, in some cases, easy to bypass depending on the version control provider and repository configuration. The PR Review Status Check provides a more reliable and predictable merge gate because it is driven by policy compliance rather than reviewer mechanics.

This filter excludes legacy code from the analysis based on a specified reference date. Consider this, you open a PR that modifies just three files, Code Reviews scans them and finds no new issues. Yet, the build status still fails. This happens because the status check examines the entire project, including untouched files that might contain legacy issues.

If you've enabled the Legacy Code Filter, Code Reviews's targeted review will correctly exclude those older problems. For example, if you set the reference date to "yesterday," only issues that have existed in the entire project since yesterday would be flagged in the status section. This allows your build to pass without being held up by pre-existing issues. Crucially, any items within your PR itself would remain unaffected by the reference date, no matter what it's set to. For more information on how to set up the Legacy code filter check out this guide.
​

​