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 control Thorough reviews under Settings -> Configuration -> Review depth. Turning it off selects Focused reviews. The choice applies to all repositories and takes effect on the next review, including existing PRs. Repository overrides do not change review depth.

​

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 category only appears when Cross-Repo 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, or Cross-Repo
• 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.

​

Review coverage

The Review coverage section summarizes functional validation and automation outcomes inside Code Review. Expand it to see what ran and where further setup is needed. Detailed results stay in their feature sections. On platforms without collapsible HTML, coverage appears as a text summary. 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.