> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Devin GitHub integration
> Connect Devin to GitHub to create pull requests, respond to review comments, and control repository access for your organization.
## 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, open [Settings → Connections → GitHub](https://app.devin.ai/settings/connections/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, open [Settings → Connections → GitHub](https://app.devin.ai/settings/connections/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 [**Settings** > **Repositories**](https://app.devin.ai/settings/repositories).
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 comments on PRs its sessions are working on, as long as the session has not been archived. To start a new session from any PR, see [Start Devin from a PR comment](#start-devin-from-a-pr-comment).
### Start Devin from a PR comment
You can hand work to Devin without leaving GitHub. On any open pull request in a repository connected to Devin, leave a comment that starts with `/devin` followed by what you want done:
```
/devin fix the failing lint check and push a commit
```
Devin starts a new session with that repository, uses the PR as context (taking over the PR if appropriate), and replies on the PR with a link to the session.
| Comment | What happens |
| - | - |
| `/devin ` | Starts a Devin session for the PR with your prompt |
| `/devin review` | Starts a [Devin Review](/work-with-devin/devin-review#triggering-a-review-from-a-pr-comment) of the PR |
| `/devin` | Devin replies with usage instructions |
Requirements:
* **Start of the comment** — the command must begin the comment. It is case-insensitive and works in both PR conversation comments and inline review comments.
* **Open PRs only** — comments on issues, or on closed or merged PRs, are ignored.
* **Write access** — the commenter needs `write` or `admin` permission on the repository.
* **Linked account** — the commenter's GitHub account must be [linked to their Devin account](#user-linking), and they must be a member of a Devin organization with access to the repository and permission to use Devin sessions.
If a Devin session is already working on the PR, `/devin` comments are sent to that session instead of starting a new one.
## User Linking
The GitHub App connection above is organization-wide. On top of it, individual users can link their own GitHub account to Devin so that Devin can act under their identity: pull requests Devin opens in their sessions are authored by them, and comments or reviews they submit through [Devin Review](/work-with-devin/devin-review) appear under their GitHub account.
To link a personal GitHub account:
1. Go to [Settings > **Connections**](https://app.devin.ai/account/connections) in your personal account settings
2. Find the **GitHub** row in the list of accounts
3. Click **Link** and complete the GitHub authorization
To remove the link later, click **Unlink user** on the same row. Devin revokes the OAuth token with GitHub when you unlink.
**The GitHub row only appears if your organization has a GitHub connection.** If it is missing, confirm that you are a member of a Devin organization whose GitHub integration is set up. GitHub Enterprise Server instances appear as separate **GitHub Enterprise** rows labeled with the host, and are linked the same way.
For Devin to open pull requests as the linked user, an admin also needs to set **Open PRs as** under [**Settings** > **Devin**](https://app.devin.ai/settings/devin) > **Pull requests**:
* **Devin**: always opens pull requests as Devin
* **User**: opens as the user when their git account is linked, otherwise as Devin
* **User only**: opens as the user, and fails if their git account is not linked (automations and service users still fall back to Devin)
Two related settings live in the same **Pull requests** section:
* **Allow PRs to be opened by session participants**: lets Devin open a PR as a person who contributed to the session, not only the person who started it.
* **Require session access for PR comments**: only forwards PR comments to a Devin session when the commenter has access to that session. Enterprise admins can enforce this for all organizations.
## 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` | Allow Devin to resolve dependabot alerts on your behalf (i.e. bumping dependency versions) |
| `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 and teams of an organization, including for GitHub team sync |
| `organization administration` | Allow Devin to read organization settings such as the default repository permission, used for GitHub team sync |
| `custom organization roles` | Allow Devin to read custom organization roles, used for GitHub team sync |
| `code scanning alerts` | Allow Devin to view code scanning alerts for a repository in order to help fix them |
| `secret scanning alerts` | Allow Devin to view secret scanning alerts for a repository in order to help fix them |
| `code quality` | Allow Devin to view code quality findings for a repository in order to help fix them |
| `webhooks` | Allow Devin to view the hooks configured for a repository, e.g. linting and type checking |
**Read** and **write** access to:
| Permission | Description |
| - | - |
| `actions` | Allow Devin to view the actions configured for a repository in order to understand if Devin’s changes pass CI, and to rerun workflows |
| `checks` | Allow 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 |
| `repository creation` | Allow Devin to create new repositories in your organization, e.g. when starting a new project |
| `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.
When Devin's GitHub App requests new permissions, GitHub emails your organization admins to approve them in the installation settings. Devin keeps working with the permissions already granted until then.
## 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 *committer*. GitHub verifies signatures against the committer email, but in any **Commit authoring** mode where the committer is the requesting user ("Co-authored (you + Devin)", "You only", "Devin as author, you as committer"), Devin commits with each user's own email as the committer — which won't match a single shared GPG key. Before relying on this setup, have an enterprise admin set **Commit authoring** under [Enterprise Settings > Devin](https://app.devin.ai/settings/enterprise-devin) > **Git commit attribution** to **"Devin only"**, **"Co-authored (Devin + you)"**, or **"You as author, Devin as committer"**. This enterprise-wide setting overrides each user's personal **Git commit author** preference; while it is left at **Per-user (Default)**, each user's own choice under [Settings > Preferences](https://app.devin.ai/settings/preferences) applies. If your organization isn't part of an enterprise, there is no org-wide control: every user who starts Devin sessions must set their personal **Git commit author** under [Settings > Preferences](https://app.devin.ai/settings/preferences) to one of those modes.
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 *committer* 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 → Resources → 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 can create new repositories in your GitHub account only if the `repository creation` permission is granted.
## 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
* 140.232.64.0/26
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.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.