> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gitar.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Cross-Repo Analysis
> Catch changes that break another repository in your organization
export const ThemeImage = ({src, alt, width}) => {
let lightSrc, darkSrc;
if (src.includes("-light.")) {
lightSrc = src;
darkSrc = src.replace("-light.", "-dark.");
} else if (src.includes("-dark.")) {
darkSrc = src;
lightSrc = src.replace("-dark.", "-light.");
} else {
lightSrc = src;
darkSrc = src;
}
const style = width ? {
maxWidth: width,
marginInline: "auto"
} : undefined;
return
;
};
Cross-Repo Analysis is available on the **Enterprise** plan.
## Overview
Gitar checks your pull request against other repositories in your organization and reports what the change breaks in them.
Repositories are related by more than imports. A route path, an event name, or a database column that two repositories have to agree on ties them together, with no shared package between them.
Every relevant repository in your organization, on every review. Nothing to link.
Unlimited linked repositories, discovered automatically as the organization grows.
A route, an event name, or an error code ties two repositories together. No shared package required.
A service in a GitHub repository and a client in a GitLab repository are asserted against each other.
## What it catches
| The change | Impacts |
| - | - |
| A route, a wire field, an enum value, or an error code | the client still calling it or branching on the value you removed, named by repository, file, and function |
| A shared CI action, workflow, or base image | the repositories whose builds go red on their next version bump |
| Code that compiles against a symbol from another repository | that the symbol is not on that repository's default branch yet, only in an unmerged PR or an unpinned branch |
| One side of a feature | the counterpart the other repository never got, like a UI key with no server handler or an event with no subscriber |
| A table, column, or file layout | the downstream job, warehouse model, or migration that has to move with it |
| A published contract, under a patch version bump | that callers auto-upgrade into the break, so it needs a major tag or a deprecation window |
## How it works
It narrows the whole organization down to the repositories your change can reach.
Each impact is verified against your PR before you see it.
Each finding is anchored on the line in your PR that changed the contract, names the affected repository and the file and function in it that breaks, and gives your options: keep the change backward compatible, or sequence the rollout so nothing breaks at runtime.
A finding says which end to fix. Some are yours to hold in this PR, some are a follow-up in the other repository, and some need a change at both ends to land safely.
Findings are labeled **Cross-Repo** and post inline like any other [code review finding](/features/code-review).
## Inspect Cross-repo findings
Enterprise organization members can open **Dashboard -> Cross-repo** to explore repository connections and filter findings by repository, status, or fix location. Only admins can change the feature setting.
Admins use the Cross-repo toggle on that page to turn the feature on or off. Turning it off stops future processing and retains its history.
Select a finding to inspect the changed and affected repositories. Expand **Technical details** to see the original finding and suggested fix location.
## Coverage
Gitar builds a summary of a repository the first time it reviews one, and refreshes it as the repository changes. Nothing to enrol, no backfill to run.
Coverage therefore builds as Gitar sees more of your organization. A review opened the day the feature is turned on may not reach everything yet.
## Repository visibility
A pull request is only ever matched against repositories its readers could already see. A private repository is matched against every repository in your organization. A public one is matched only against other public repositories, plus itself.
A public pull request therefore never surfaces a finding that names a private repository or describes its contents.
## Naming and excluding repositories
Gitar gets this right in most cases. To customize it, commit `.gitar/cross-repo.md` and describe the relationships in natural language: which repositories depend on this one, what has to stay consistent between them, and what to leave alone.
```markdown theme={null}
`my-org/frontend` and `my-org/mobile` call the API this repository publishes.
`my-org/data-jobs` reads the tables this repository owns.
Ignore `my-org/frontend-archive`.
```
Put the file in your [configuration repository](/configuration/configuration-repository) to apply it across the organization, or in a single repository to scope it there. When both exist, the organization's rules load first and the repository's file adds to them.
## Related
For interactions between related open PRs, use [Cross-PR Analysis](/features/cross-pr-analysis).
Cross-Repo Analysis checks shared contracts. [Knowledge](/features/knowledge) supplies team conventions and connected context, while [Functional Validation](/features/functional-validation) checks the requirements the PR claims to implement.
How findings are posted, resolved, and tracked
Where the Cross-Repo category is reported across your organization
The comment the Code Review section lives in
What each plan includes
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.