Git

Use the Git integration to connect ResolveAI to your codebase — to query code during investigations, pull relevant evidence, and propose code changes for you to review. Resolve’s Git integration is designed to fit how your organization is set up. It supports both a cloud-only and a hybrid (Satellite-based) architecture, and multiple authentication methods, so a single integration can cover github.com, GitHub Enterprise (Cloud or Server), GitLab, Bitbucket, Azure DevOps, and self-hosted Git.

---

​

How Resolve connects to your codebase through Git

Connecting ResolveAI to your code comes down to two independent choices:

1. Where Git commands run: Git on Cloud (Resolve-managed) or Git on Satellite (your Kubernetes / ECS).
2. How Resolve authenticates: github (ResolveAI’s App for GitHub), ghe (Bring-Your-Own GitHub App), or token (PAT). All three work on both Cloud and Satellite.

---

​

1. Choosing an execution plane: Cloud or Satellite

Your first decision is where Resolve actually clones, fetches, and queries your repositories. The right choice depends on your network reachability, your data residency requirements, and how much infrastructure your team is prepared to operate. The Resolve Satellite is supported on Kubernetes and on AWS ECS Fargate. The Kubernetes deployment stores repositories on a gitVolume (PVC is recommended for production); the ECS deployment uses an EFS volume. Both are functionally identical, so the choice comes down to whichever infrastructure your team already operates. Once you’ve decided, follow the matching setup guide:

• Set up Git on Cloud for Resolve-managed execution
• Set up Git on Satellite (Kubernetes) for in-cluster execution
• Set up Satellite on ECS for AWS Fargate execution

---

​

2. Choosing an authentication method

After picking an execution plane, decide how Resolve proves identity to your Git host. All three auth types work on both Cloud and Satellite — the choice is driven by which Git host your code lives on, your security policy, and how you want to manage the Git App.

• github — Connects to github.com through ResolveAI’s App for GitHub. You complete an OAuth-style installation, and Resolve handles token rotation automatically.
• ghe — Connects through a custom GitHub App that you own, on any GitHub variant (github.com, GitHub Enterprise Cloud, or GitHub Enterprise Server). You provide the App ID, installation ID, and private key, and Resolve calls the API base URL you configure.
• token — Connects to non-GitHub providers (GitLab, Bitbucket, Azure DevOps, self-hosted Git) or to GitHub via PAT. Resolve authenticates with the username and personal access token you provide.

​

Match your setup to an auth type

Once you’ve decided, follow the matching walkthrough:

• Connect via ResolveAI’s App for GitHub for github auth on github.com
• Bring Your Own GitHub App for ghe auth (github.com, GHE Cloud, or GHE Server)
• For token auth, first create the PAT, then complete the connection under Option 3 in the Cloud or Satellite guide

---

​

What Resolve can do once connected: reads vs writes

These behaviors apply to both Cloud and Satellite:

• Reads are always enabled. Cloning, fetching, searching, reading files, viewing history, generating diffs, and inspecting blame data.
• Write/remediation tools (proposing code changes, opening PRs) are controlled by disableWrites:
  • With a github or ghe auth config, writes are enabled by default.
  • With token-only auth, writes are disabled by default.
  • Set disableWrites explicitly in your connection config to override either default.

For the full schema (authConfigs, tokenAuthCredentials, gheAuthCredentials, disabledSubcommands, certificate overrides), see the Git on Cloud or Git on Satellite setup guide.

---

​

Creating access tokens

When you use token auth, you provide a username and personal access token (PAT) that Resolve uses to authenticate to your Git host. The steps below apply to every execution plane. Create the token here, then follow your setup guide (Cloud, Satellite, or ECS) for where to store it. Every token can be created in one of two flavours, regardless of provider:

• Write (remediation), recommended: Resolve investigates and also proposes fixes, pushing a branch and opening a pull/merge request for your review. Requires write scopes on the token and disableWrites: false on the connection.
• Read-only (restricted): Resolve clones code and reads commits, branches, pull/merge requests, pipelines/CI, and metadata, but cannot open PRs/MRs. This is the technical default for token-only auth (disableWrites: true). Choose it only if your policy requires investigate-only access.

Pick the flavour that matches how you want to use Resolve.

​

GitHub

GitHub supports fine-grained and classic PATs.

Fine-grained token (recommended)

1. Go to Settings > Developer settings > Personal access tokens > Fine-grained tokens.
2. Click Generate new token and set a name and expiration.
3. Choose the resource owner and select the repositories to grant access to.
4. Set repository permissions:
   • Read and write on Contents (code) and Pull requests. These two enable pull-request creation. Set them to Read-only if you only need investigation reads.
   • Read-only on Metadata (mandatory), Actions, Checks, Commit statuses, Deployments, Discussions, Issues, and Merge queues.
5. If your org uses SSO, authorize the token for SSO after creation.
6. Generate and copy the token.

Classic token

1. Go to Settings > Developer settings > Personal access tokens > Tokens (classic).
2. Generate a token and set an expiration.
3. Select scopes:
   • Private repositories: repo.
   • Public-only workflows: public_repo.
4. Authorize SSO for your org if required.
5. Copy the token.

Classic PATs with repo scope are broad. Prefer fine-grained PATs when possible.

​

GitLab

GitLab access is gated by two independent controls, and you must satisfy both:

1. Token scopes: the checkboxes you select when creating the PAT.
2. Membership role: the role (Guest, Reporter, Developer, and so on) the token’s owner has on the projects or groups you connect.

A token’s effective access is the intersection of its scopes and the owner’s role. An api-scoped token owned by a Reporter still cannot push or open merge requests. Pick the flavour that matches what you want Resolve to do.

Merge-request creation (write, recommended)

Lets Resolve investigate and open merge requests for your review. Includes every read capability, plus branch push and MR creation.

1. Go to Preferences > Access Tokens (or use a project/group access token).
2. Create a token with an expiration.
3. Select scope:
   • api: the only read-write API scope. It covers MR creation and also includes Git-over-HTTPS clone/fetch/push, so it subsumes read_repository/write_repository.
   write_repository is not sufficient on its own. It only enables Git push over HTTPS and does not support API authentication, so it cannot create a merge request.
4. Ensure the owner has at least the Developer role on the connected projects/groups. Developer is the minimum role that can push branches and create merge requests.
5. Copy the token.

Set disableWrites: false on the connection to allow write/remediation tools.

Read-only (restricted)

Lets Resolve clone code and read commits, branches, merge requests, pipelines, CI job logs, and project metadata, but not open merge requests. Choose this only if your policy requires investigate-only access.

1. Go to Preferences > Access Tokens (for a personal token), or use a project/group access token to scope it to specific repos.
2. Create a token with an expiration.
3. Select scopes:
   • read_repository: clone/fetch code over HTTPS.
   • read_api: read merge requests, pipelines, jobs, commits, and metadata via the GitLab API.
   Both are required. read_repository alone does not grant API reads of MRs/pipelines, and read_api alone does not grant Git-over-HTTPS clone.
4. Ensure the owner has at least the Reporter role on the connected projects/groups. On private projects, Guest cannot read code, so Reporter is the minimum.
5. Copy the token.

Keep disableWrites: true (the default for token-only auth) for this flavour.

​

Other providers (Bitbucket, Azure DevOps, self-hosted)

Token auth works with any provider that supports HTTPS PATs. The principle is the same as above: grant the minimum the flavour needs.

• Read-only: scopes that allow repository read/clone plus reading pull requests and pipelines/builds (e.g. Bitbucket Repositories: Read + Pull requests: Read + Pipelines: Read; Azure DevOps Code (Read) + Build (Read)).
• Write (remediation): add the provider’s repository-write and pull-request-write scopes so Resolve can push branches and open PRs.

If your host uses a custom or self-signed certificate, see the certificate override options in the Satellite setup guide.

---

​

Get Started