How Gitar Works

Gitar reviews changes in their engineering context. It combines the diff with code structure and team knowledge, then investigates the questions that need more evidence.

​

What a review covers

A Gitar review checks code behavior and connects the change to the requirements and systems around it. The Review coverage section on the PR shows outcomes for functional validation and automation. Feature availability follows the organization’s plan.

​

Code structure informs the review

Gitar uses structural outlines to locate functions and types, then reads the implementation when a change needs more context. For example, changing a shared helper can require checking its callers and tests even when those files are outside the diff. Structural context helps locate the code, and Gitar examines the implementation to assess the effect.

​

What context Gitar uses

Gitar selects context for the task and reads further when a finding needs supporting evidence. A configuration repository shares guidance across the organization. Skills provide reusable procedures that Gitar loads when a rule or PR comment calls them.

​

Review across repositories

Cross-Repo Analysis supports unlimited linked repositories and discovers relevant connections across the organization. A GitHub service and its GitLab client can be checked together. Gitar uses repository summaries to identify likely connections, then reads relevant files to verify the impact. Findings name the affected repository and explain which side needs a fix. See Cross-Repo Analysis for coverage and visibility rules.

​

Evidence in the review

Findings land on the changed lines they concern and explain the behavior behind the issue. Source citations connect learned guidance to its origin, so a team convention can be checked against the instruction or conversation that established it. The Code Review section collects findings and the verdict in the existing PR dashboard comment. Later pushes refresh that comment and revisit earlier findings.

​

From findings to validated changes

Gitar can apply a suggested fix when requested, or push fixes automatically under auto-apply. Subsequent CI results provide evidence about whether the change builds and passes the configured checks. Functional validation separately tracks whether the implementation addresses the linked issue’s objectives. Passing CI and covering the requested behavior answer different questions. If a Gitar fix introduces a CI failure, automatic recovery can continue the repair without another developer request. Findings and risk also inform configured approval and merge criteria.

​

Data access and controls

Repository access follows the organization’s connected code hosts. Custom integrations use the credentials and allowed tools configured for each connection. Cross-repository visibility controls which repositories can contribute context to a review. Gitar runs work in isolated environments and uses repository caches to support repeated reads. Processing and retention details belong to Security. Enterprise organizations can choose their own model account through Bring Your Own Model. Fixes land as additional commits. Gitar merges only when Auto-Merge is enabled and its criteria and platform checks allow it.