> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.
# GitHub
> Work with Devin directly in your repos
## Why integrate Devin with GitHub?
Integrating Devin with your GitHub organization enables Devin to create pull requests, respond to PR comments, and collaborate directly within your repositories. This allows Devin to function as a full contributor on your engineering team.
To get started, navigate to [app.devin.ai](http://app.devin.ai) > **Settings** > **Integrations** > **GitHub**, click **Add Connection**, and follow the prompts. You will select which repositories Devin can access and review the required permissions.
**Using GitHub Enterprise Server or GitHub Enterprise Cloud with Data Residency?** See the [GitHub Enterprise Server Integration guide](/enterprise/integrations/github-enterprise-server) for setup instructions.
## Setting up the Integration
You must be an admin of your GitHub organization to create and manage the Devin integration. Having trouble? Check out our [Common Issues](/admin/common-issues#i-m-unable-to-connect-my-github-organization).
1. In your Devin account at [app.devin.ai](http://app.devin.ai), navigate to **Settings** > **Integrations** > **GitHub** and click **Add Connection**.
2. If you are not already logged in to GitHub, you will be prompted to authenticate.
3. Select the GitHub organization you want to connect to Devin.
4. Choose whether to grant Devin access to **All repositories** or **Select repositories** to control which repositories Devin can access.
5. After completing the GitHub authorization, you will be redirected to Devin settings where you can confirm the integration is active.
We recommend enabling branch protection rules on your main branch to ensure all required checks pass before Devin can merge changes.
## Using Devin with the GitHub Integration
### For Core and Teams users
Once the integration is configured, you can @mention repositories directly in your prompts within the Devin web application.
### For Enterprise users
Once the integration is configured, you can delegate repositories to specific organizations from **Enterprise Settings** > **Repository Permissions**.
If you are working with a repository for the first time, we recommend completing the [development environment setup in the onboarding flow](/onboard-devin/environment) to ensure Devin has accurate, up-to-date information about your codebase.
Devin automatically responds to PR comments as long as the session has not been archived.
## Managing Devin’s Permissions in GitHub
During setup, you can grant Devin access to **all repositories** in your organization or limit access to **specific repositories**.
You can adjust repository access at any time through GitHub's settings:
1. Navigate to your GitHub organization's **Settings** > **GitHub Apps** (e.g., `https://github.com/organizations//settings/installations`)
2. Select **Configure** for the Devin.ai integration
3. Under **Repository access**, choose to grant access to all repositories or select specific repositories
4. Click **Save** to apply your changes
Devin requires the following permissions:
**Read** access to:
| Permission | Description |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `dependabot alerts` | Allows Devin to resolve dependabot alerts on your behalf (i.e. bumping dependency versions) |
| `actions` | Allows Devin to view the actions configured for a repository in order to understand if Devin’s changes pass CI |
| `deployments` | Allow Devin to view which versions of a repository were deployed |
| `metadata` | Allow Devin to view crucial metadata about a repository such as who owns it |
| `packages` | Allow Devin to view which versions of a repository were shipped as a package |
| `pages` | Allow Devin to consult pages associated with a repository, e.g. to view documentation |
| `repository security advisories` | Allow Devin to view security advisories related to a repo in order to help fix security issues |
| `members` | Allow Devin to view members of an organization |
| `webhooks` | Allow Devin to view the hooks configured for a repository, e.g. linting and type checking |
**Read** and **write** access to:
| Permission | Description |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| `checks` | Allows Devin to view and report check results for a repository in order to understand and communicate if Devin’s changes pass CI |
| `commit statuses` | Allow Devin to view and set commit statuses to indicate if a commit passes CI |
| `contents` | Allow Devin to contribute to the codebase |
| `discussions` | Allow Devin to contribute to discussions |
| `issues` | Allow Devin to open new issues |
| `pull requests` | Allow Devin to create new PRs |
| `projects` | Allow Devin to view and manage projects associated with a repository, e.g. to retrieve information about a task |
| `workflows` | Allow Devin to set up new workflows, e.g. to help configure CI/CD |
These permissions enable Devin to work in your repositories as a regular contributor—pushing branches, opening pull requests, and participating in PR discussions.
## Pull Request Templates
When Devin creates a pull request, it uses a template from your repository to structure the PR description. If you provide a template, Devin follows its format when submitting PRs to GitHub.
### Devin-specific template (recommended)
You can provide Devin with its own template without modifying your default human-facing template by adding a file named `devin_pr_template.md` in one of the supported `PULL_REQUEST_TEMPLATE` locations below. This is useful if you want Devin to include additional context, such as a reviewer checklist or a Mermaid diagram of modified files.
### Template search order
Devin searches for templates in the following order and uses the first match:
1. PULL\_REQUEST\_TEMPLATE/devin\_pr\_template.md
2. docs/PULL\_REQUEST\_TEMPLATE/devin\_pr\_template.md
3. .github/PULL\_REQUEST\_TEMPLATE/devin\_pr\_template.md
4. pull\_request\_template.md
5. docs/pull\_request\_template.md
6. .github/pull\_request\_template.md
If no template is found, Devin uses its default PR description format.
If you want Devin to use your existing `pull_request_template.md`, copy or symlink it to one of the `devin_pr_template.md` paths listed above.
For more on GitHub pull request templates (supported locations, multiple templates, query parameters, etc.), see the GitHub Docs: Creating a pull request template for your repository.
### Commit Signing
To sign Devin's commits with GPG, configure the key in your [environment](/onboard-devin/environment/blueprints) so it persists across sessions. Generating the key in a session terminal will not work — every Devin session boots from a fresh copy of the machine image, so any keys created mid-session are discarded when the session ends.
GPG signing via environment config only produces **Verified** commits when Devin is the *commit author*. GitHub verifies signatures against the author identity, but in any **Commit authoring** mode where the author is the requesting user (e.g., "Co-authored", "User only", "User as author, Devin as committer"), Devin overrides `user.email` per-session with each user's own email — which won't match a single shared GPG key. Set your org's [Commit authoring](https://app.devin.ai/settings/profile) mode to **"Devin only"** or **"Devin as author, user as committer"** before relying on this setup.
Set this up at the **org-wide** layer (or **enterprise** layer, if all of your orgs need it) so that every repo gets a signed-commit configuration:
1. Create (or pick) a dedicated GitHub user account that will own both the commit author identity *and* the credentials Devin pushes with — e.g., `devin@company.com`. Using one account for both makes the signing setup straightforward; using two splits the configuration described below across both.
2. Generate a GPG key locally with that account's email as the UID, following [GitHub's instructions](https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key).
3. Upload the **public** key to the GitHub account whose verified email matches the GPG UID, under [GitHub Settings > SSH and GPG keys](https://github.com/settings/keys). GitHub verifies signatures against the *commit author* identity, not the pushing identity — the public key must live on the account that owns the email in `user.email`. (If that's the same dedicated account you're pushing as, you only need to do this once.)
4. Export the **private** key, base64-encode it, and add it (along with the matching `GIT_USER_NAME` / `GIT_USER_EMAIL`) as secrets in [Settings > Secrets](https://app.devin.ai/settings/secrets).
5. In your [org-wide environment config](https://app.devin.ai/settings/environment), import the key and enable signing on every session start. See the copy-paste [GPG commit signing example](/onboard-devin/environment/templates#gpg-commit-signing) for the full YAML.
The committer email (`user.email`) must match a UID on the GPG key, and that same email must be a verified email on the GitHub account where you uploaded the public key. If any of these three don't match, GitHub will show the commit as **Unverified** even though the signature itself is valid.
### Security Considerations
* **Branch protection:** We recommend enabling branch protection rules on your main branch to ensure all required checks pass before Devin can merge changes.
* **Organization-level permissions:** Devin uses the permissions granted at the organization level, not the permissions of the individual user running a session.
* **Consistent access:** All users with access to both the GitHub and Devin organizations share the same Devin integration permissions.
* **Repository creation:** Devin cannot create new repositories in your GitHub account.
## IP Allowlisting
If your organization requires IP allowlisting for GitHub access, add the following IP addresses:
* 100.20.50.251
* 44.238.19.62
* 52.10.84.81
* 52.183.72.253
* 20.172.46.235
* 52.159.232.99
* 4.204.199.103
These IP addresses may change in future updates. We recommend monitoring our release notes for any changes.
## Troubleshooting: GitHub organization connected to the wrong Devin organization
If your GitHub organization is already connected to a Devin organization you don't have access to, a GitHub org admin can remove the existing installation and reinstall it under a different Devin organization.
We recommend confirming with the owner of the current Devin organization before removing the installation.
1. Go to [github.com/settings/installations](https://github.com/settings/installations) and click **Configure** next to **Devin.ai Integration**.
If needed, switch to the correct GitHub organization context using the **Go to settings page** dropdown in the top right.
2. On the installation page, scroll to the **Danger zone** section and click **Uninstall** to remove the Devin.ai Integration from the GitHub organization.
3. Return to [app.devin.ai](https://app.devin.ai) and refresh the page. You can now reinstall the GitHub integration under your Devin organization.
## GitHub Integration FAQs
Yes, you can connect either a GitHub Organization or a personal GitHub account to your Devin organization. However, we recommend connecting the account that has the appropriate permissions for Devin to access the repositories your team needs.
Only users who are members of the organization that installed the GitHub integration can use it in their Devin sessions. Devin inherits access to the GitHub integration based on the user's organization membership.
Encryption keys are managed by AWS KMS and rotated periodically.