Skip to main content

​
Overview

Gitar reviews your pull requests on your DevOps platform. Findings land on the PR itself, so there is no separate tool to check.

Security Analysis

Vulnerabilities, unsafe patterns, input validation

Bug Detection

Logic errors, null pointer risks, edge cases

Performance

Algorithm complexity, database queries, memory usage

Code Quality

Readability, maintainability, best practices

​
How It Works

Code reviews run automatically when:
  • A new pull request is created
  • New commits are pushed to an open PR
One exception: a pull request holding a single commit that reverts an earlier one is not reviewed. The reverted commit was reviewed when it first went in, so reviewing the revert repeats a decision the original pull request already made. 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.

​
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: where a finding rests on a convention Gitar learned from your codebase, it links the file that convention came from

​
Providing Feedback

Gitar learns from your feedback on review findings:
  • Reply to findings: Comment on a finding thread with responses like “this is intentional” or “already fixed”. Gitar processes the reply and dismisses the finding. On GitLab you can reply without the gitar prefix on inline findings.
  • 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.
  • Resolve / unresolve threads: Resolving a finding thread on GitHub or GitLab dismisses the finding in real time. Unresolving reopens it. On GitLab you can also thumbs-down a finding to dismiss it.
  • 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.

​
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.