Skip to main content

Overview

Gitar automatically reviews your pull requests on GitHub and GitLab, providing AI-powered feedback on security, bugs, performance, edge cases, and code quality.

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
Reviews appear directly on your PR — inline on the lines that have issues, summarized in the Gitar dashboard comment, and grouped into a single review. No context switching to external tools.

How It Works

Automatic Triggers

Code reviews run automatically when:
  • A new pull request is created
  • New commits are pushed to an open PR

Review Process

Gitar analyzes your code changes through multiple specialized checks:
  • Security analysis: Vulnerabilities, unsafe patterns, input validation
  • Bug detection: Logic errors, null pointer risks, edge cases
  • Performance analysis: Algorithm complexity, database queries, memory usage
  • Code quality: Readability, maintainability, best practices

Custom Code Review Instructions

Allows the agent to leverage custom rules, checks or gotchas to tailor the review process to specific project requirements. It can be configured by adding a markdown file containing instructions under the .gitar/review directory. Note that multiple files can be used to organize instructions based on different aspects. For example, we created a file named gitar-gotchas.md that documents some gotchas very specific to Gitar’s codebase, like using info! for logging that requires operational visibility or leaving debug! for debugging locally, since our telemetry only renders logs with severity info or higher.

Including Specific Files

You can include content from specific files using the @ syntax with a relative path. Paths are first resolved relative to the source file, with a fallback to the repository root if not found. Example: Given the following directory structure:
your-repo/
  .gitar/
    review/
      gotchas.md
    documents/
      rust_best_practices.md
  shared/
    common_rules.md
From .gitar/review/gotchas.md, you can include files using either approach:
# Gotchas for Rust Code

@../documents/rust_best_practices.md

@shared/common_rules.md

# Other project-specific gotchas
...
  • @../documents/rust_best_practices.md — uses ../ to navigate up from review/ to .gitar/, then into documents/
  • @shared/common_rules.md — not found relative to review/, so falls back to repo root resolution
This works recursively—an included file can itself include other files.

Review Output

Gitar publishes review feedback in two places on your PR:
  1. 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.
  2. Dashboard comment — Code Review section — a consolidated view on the Gitar dashboard comment showing the overall verdict, severity breakdown, and resolved-finding tracking.
Each finding includes:
  • Category: Security, Bug, Performance, Edge Case, or Code Quality
  • Severity: Critical, Important, or Suggestion
  • Short description: One-line summary of the issue
  • Details: Expanded explanation with a link to the specific file and line

Design Principles

Gitar’s code review is built around a few core principles that shape how feedback is delivered:

One Dashboard Comment, Kept Up to Date

The Gitar dashboard comment is the single source of truth for the overall state of a PR. It consolidates the code review summary, CI analysis, and rule evaluations in one place. When you push new commits, Gitar updates the existing comment rather than posting a new one — so your PR timeline stays clean.

Resolved Findings Tracking

As you address issues and push fixes, Gitar tracks what’s been resolved. The dashboard shows a collapsible section with resolved findings, so you can see your progress at a glance. This helps you stay confident that you’re making headway and prevents Gitar from repeatedly flagging issues you’ve already fixed.

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.