Code Review

​

Overview

Gitar reviews PRs using the surrounding code and the team’s engineering context. Findings land on the changed lines, with explanations and suggested fixes.

​

Beyond the changed lines

Gitar uses AST-informed code structure to navigate the implementation, then reads related files and searches for callers to investigate the effect of a change. See How Gitar Works for the context used during review, including web documentation and connected knowledge sources.

​

Large PRs and review volume

Gitar supports unlimited changed files per PR. Large changes remain eligible for review, including changes spread across a monorepo. Gitar prioritizes relevant code and condenses repetitive changes to keep large diffs reviewable. Generated files and other low-value content may be excluded from review. Enterprise includes unlimited review volume per author, including allowed bot authors. Other plans follow the usage policy.

​

How It Works

Code reviews run automatically when:

• A new pull request is created
• New commits are pushed to an open PR

Gitar skips a PR containing only a single revert commit. This also applies when the original change was never reviewed by Gitar. Push any commit beyond the revert and Gitar reviews the pull request as usual, because at that point it is no longer a plain revert. Everything else still runs either way, including CI analysis and rule evaluation.

​

Review depth

Review depth controls which verified findings Gitar reports. Enterprise organization admins choose the default under Settings -> Configuration -> Review depth. To set a different depth for a repository, select Customize on its row and choose Focused or Thorough. Changes take effect on the next review, including existing PRs. Repositories inherit the organization default until an override is saved. Resetting an override restores inheritance. Previously saved review depth settings are retained.

​

Custom Code Review Instructions

Add your own rules, checks, or gotchas to tailor the review to your project. Commit a markdown file under the .gitar/review directory. Use several files to organize instructions by topic. Gitar’s own repository, for example, has a gitar-gotchas.md covering conventions specific to that codebase. One of them is to use info! for logging that needs operational visibility and leave debug! for local debugging, since its telemetry only renders logs at severity info or higher. One file can pull in another with the @ syntax, so shared guidance lives in one place. See Custom Review Instructions for the directory layout and include resolution.

​

Review Output

Gitar publishes review feedback in two places on your PR:

• Inline review comments: every unresolved finding is posted on the exact file and line it applies to, so feedback lands where you’re reading the code.
• Dashboard comment, Code Review section: a consolidated view on the Gitar dashboard comment showing the overall verdict, severity breakdown, and resolved-finding tracking.

The dashboard comment is the single source of truth for the overall state of a PR, holding the code review summary, CI analysis, and rule evaluations in one place. When you push new commits, Gitar updates that comment instead of posting a new one, so your PR timeline stays clean. Resolved findings move into a collapsible section as you push fixes, so what is left to address stays at the top. The Cross-Repo and Cross-PR categories only appear when Cross-Repo Analysis or Cross-PR Analysis is turned on for your organization. To change how that summary reads, set review summary instructions for your organization. Each finding includes:

• Category: Security, Bug, Performance, Edge Case, Code Quality, Cross-Repo, or Cross-PR
• Severity: Critical, Important, or Minor
• Short description: One-line summary of the issue
• Details: Expanded explanation with a link to the specific file and line
• Citations: links to available sources for learned guidance. See Citations in findings.

​

Citations in findings

Citations make team-specific review advice traceable. When a finding relies on learned guidance, its explanation can link to the instruction or earlier conversation behind that guidance. The link appears within the finding, alongside the reasoning about the changed code. See Knowledge source citations for how sources are retained and when a citation becomes a link.

​

Verification

Verification follows Code Review and collects recorded outcomes, including linked issue objectives and rule results. It can appear without a code review. Covered objectives and checked expectations describe assessments against code, without claiming that runtime tests ran. The header keeps one compact badge per feature, such as Objectives 5/7, Rules 3/4 met and Repos 1 inspected. Knowledge shows check and lens counts. The rule ratio excludes skipped checks and recorded actions. The section opens for unmet requirements. A knowledge-backed finding opens it while that finding remains open in the current review. Settled outcomes collapse, even when Code Review still requests changes. Each feature has its own collapsed section and outcome badges. Open a feature to read up to five successful names. Unmet requirements stay visible without another toggle. gitar display:verbose adds remaining names and supporting evidence. Platforms without collapsible HTML show the same results as headings and compact rows. The risk label appears separately in expanded Code Review, since risk describes the whole change rather than which checks ran.

​

Providing Feedback

Feedback controls how Gitar handles findings on the current PR:

• Reply to a finding with an explanation. A confirmed fix resolves it. An invalid finding is dismissed. A decision to leave it unfixed closes it without counting it as fixed. On GitLab, replies to inline findings need no gitar prefix.
• Reply gitar fix: Every inline finding includes a “Reply gitar fix to apply this suggestion” footer. One reply and Gitar pushes the fix.
• One-click apply: On GitHub, check the box next to a suggested fix to apply it. On GitLab, react with the checkmark emoji. Gitar commits the fix to your branch. When a finding has multiple fixes, each one is numbered.
• Resolving a finding thread on GitHub closes it without marking it fixed or invalid. Unresolving that thread reopens it. On GitLab, a thumbs-down reaction dismisses a finding.
• Stale findings: When code is deleted or rewritten between review iterations, Gitar automatically resolves findings that pointed at the removed code.
• Ambiguous replies: If your reply is unclear, Gitar asks a follow-up question instead of guessing.

Your feedback persists across review iterations. Gitar won’t re-report issues you’ve already dismissed. With Knowledge enabled, explanations in review comments can also teach Gitar conventions for future PRs.

​

Merge Blocking

Gitar can block PR merges based on its code review verdict severity. Configure a threshold in your organization settings, and Gitar submits a blocking review on the PR when the verdict meets or exceeds it. See Block Merge for details.

​

Auto-Approve

Gitar can automatically approve PRs after a clean review based on criteria you define. See Auto-Approve for details.

​

Auto-Merge

After auto-approve, Gitar can arm your platform’s native auto-merge so the PR merges once all other checks pass. See Auto-Merge for details.