GitHub

Warum Devin mit GitHub integrieren?

Die Integration von Devin mit deiner GitHub-Organisation ermöglicht es Devin, Pull Requests zu erstellen, auf PR-Kommentare zu antworten und direkt in deinen Repositories zusammenzuarbeiten. So kann Devin als vollwertiges Mitglied deines Engineering-Teams fungieren. Um zu beginnen, gehe zu app.devin.ai > Settings > Integrations > GitHub, klicke auf Add Connection und folge den Anweisungen. Dabei wählst du aus, auf welche Repositories Devin zugreifen kann, und überprüfst die erforderlichen Berechtigungen.

Verwendest du GitHub Enterprise Server oder GitHub Enterprise Cloud mit Data Residency? Siehe den GitHub Enterprise Server Integrationsleitfaden für Einrichtungsschritte.

Einrichten der Integration

Sie müssen Administrator Ihrer GitHub-Organisation sein, um die Devin-Integration zu erstellen und zu verwalten. Gibt es Probleme? Sehen Sie sich unsere Seite zu häufigen Problemen an.

Melden Sie sich in Ihrem Devin-Konto unter app.devin.ai an, navigieren Sie zu Settings > Integrations > GitHub und klicken Sie auf Add Connection.

Wenn Sie noch nicht bei GitHub angemeldet sind, werden Sie zur Authentifizierung aufgefordert.

Wählen Sie die GitHub-Organisation aus, die Sie mit Devin verbinden möchten.

Wählen Sie aus, ob Sie Devin Zugriff auf All repositories oder Select repositories gewähren möchten, um zu steuern, auf welche Repositories Devin zugreifen kann.

Nach Abschluss der GitHub-Autorisierung werden Sie zu den Devin-Einstellungen weitergeleitet, wo Sie überprüfen können, dass die Integration aktiv ist.

Wir empfehlen, Branch-Schutzregeln auf Ihrem Main-Branch zu aktivieren, um sicherzustellen, dass alle erforderlichen Checks erfolgreich sind, bevor Devin Änderungen mergen kann.

Verwendung von Devin mit der GitHub-Integration

Für Core- und Teams-Nutzer

Sobald die Integration konfiguriert ist, können Sie Repositories direkt in Ihren Prompts in der Devin-Webanwendung per @mention referenzieren.

Für Enterprise-Kunden

Sobald die Integration eingerichtet ist, können Sie Repositories über Enterprise Settings > Repository Permissions bestimmten Organisationen zuordnen.

Wenn Sie zum ersten Mal mit einem Repository arbeiten, empfehlen wir, die Einrichtung der Entwicklungsumgebung im Onboarding-Flow abzuschließen, um sicherzustellen, dass Devin über präzise, aktuelle Informationen zu Ihrer Codebasis verfügt. Devin beantwortet PR-Kommentare automatisch, solange die Sitzung nicht archiviert wurde.

Verwalten von Devins Berechtigungen in GitHub

Während der Einrichtung kannst du Devin Zugriff auf alle Repositories in deiner Organisation gewähren oder den Zugriff auf bestimmte Repositories beschränken. Du kannst den Repository-Zugriff jederzeit über die Einstellungen von GitHub anpassen:

Navigiere zu den Settings > GitHub Apps deiner GitHub-Organisation (z. B. https://github.com/organizations/<org_name>/settings/installations)
Wähle Configure für die Devin.ai-Integration aus
Wähle unter Repository access, ob du Zugriff auf alle Repositories gewähren oder bestimmte Repositories auswählen möchtest
Klicke auf Save, um deine Änderungen zu übernehmen

Devin benötigt die folgenden Berechtigungen: Lesezugriff auf:

Berechtigung	Beschreibung
`dependabot alerts`	Ermöglicht Devin, Dependabot-Warnungen in deinem Namen zu beheben (d. h. Aktualisieren von Abhängigkeitsversionen)
`actions`	Ermöglicht Devin, die für ein Repository konfigurierten Actions einzusehen, um zu verstehen, ob Devins Änderungen die CI-Prüfungen erfolgreich durchlaufen
`deployments`	Ermöglicht Devin zu sehen, welche Versionen eines Repositories bereitgestellt wurden
`metadata`	Ermöglicht Devin, wichtige Metadaten zu einem Repository einzusehen, z. B. wer es besitzt
`packages`	Ermöglicht Devin zu sehen, welche Versionen eines Repositories als Paket ausgeliefert wurden
`pages`	Ermöglicht Devin, mit einem Repository verknüpfte Pages zu konsultieren, z. B. um Dokumentation einzusehen
`repository security advisories`	Ermöglicht Devin, sicherheitsrelevante Hinweise zu einem Repository einzusehen, um bei der Behebung von Sicherheitsproblemen zu helfen
`members`	Ermöglicht Devin, Mitglieder einer Organisation einzusehen
`webhooks`	Ermöglicht Devin, die für ein Repository konfigurierten Webhooks einzusehen, z. B. Linting und Typprüfungen

Lese- und Schreibzugriff auf:

Berechtigung	Beschreibung
`checks`	Ermöglicht Devin, die Check-Ergebnisse für ein Repository einzusehen und zu melden, um zu verstehen und zu kommunizieren, ob Devins Änderungen die CI-Prüfungen erfolgreich durchlaufen
`commit statuses`	Ermöglicht Devin, Commit-Status einzusehen und zu setzen, um anzugeben, ob ein Commit die CI-Prüfungen erfolgreich durchläuft
`contents`	Ermöglicht Devin, zur Codebasis beizutragen
`discussions`	Ermöglicht Devin, zu Discussions beizutragen
`issues`	Ermöglicht Devin, neue Issues zu eröffnen
`pull requests`	Ermöglicht Devin, neue PRs zu erstellen
`projects`	Ermöglicht Devin, mit einem Repository verknüpfte Projekte einzusehen und zu verwalten, z. B. um Informationen zu einer Aufgabe abzurufen
`workflows`	Ermöglicht Devin, neue Workflows einzurichten, z. B. zur Unterstützung bei der Konfiguration von CI/CD

Diese Berechtigungen ermöglichen es Devin, in deinen Repositories wie ein regulärer Contributor zu arbeiten – Branches zu pushen, Pull Requests zu eröffnen und sich an PR-Diskussionen zu beteiligen.

Pull-Request-Vorlagen

Wenn Devin einen Pull-Request erstellt, verwendet es eine Vorlage aus deinem Repository, um die PR-Beschreibung zu strukturieren. Wenn du eine Vorlage bereitstellst, hält sich Devin an deren Format, wenn es PRs auf GitHub einreicht.

Devin-spezifische Vorlage (empfohlen)

Sie können Devin eine eigene Vorlage zur Verfügung stellen, ohne Ihre standardmäßige, auf Menschen ausgerichtete Vorlage zu ändern, indem Sie eine Datei mit dem Namen devin_pr_template.md an einem der unten aufgeführten unterstützten PULL_REQUEST_TEMPLATE-Speicherorte hinzufügen. Das ist hilfreich, wenn Sie möchten, dass Devin zusätzlichen Kontext einbezieht, zum Beispiel eine Review-Checkliste oder ein Mermaid-Diagramm der geänderten Dateien.

Reihenfolge der Vorlagensuche

Devin sucht in der folgenden Reihenfolge nach Vorlagen und verwendet den ersten Treffer:

PULL_REQUEST_TEMPLATE/devin_pr_template.md
docs/PULL_REQUEST_TEMPLATE/devin_pr_template.md
.github/PULL_REQUEST_TEMPLATE/devin_pr_template.md
pull_request_template.md
docs/pull_request_template.md
.github/pull_request_template.md

Wenn keine Vorlage gefunden wird, greift Devin auf sein internes Standardformat für PR-Beschreibungen zurück.

Wenn du möchtest, dass Devin deine vorhandene pull_request_template.md verwendet, kopiere sie in einen der oben aufgeführten devin_pr_template.md-Pfade oder erstelle einen Symlink darauf.

Weitere Informationen zu GitHub-Pull-Request-Vorlagen (unterstützte Speicherorte, mehrere Vorlagen, Query-Parameter usw.) findest du in den GitHub Docs: Creating a pull request template for your repository.

Commit-Signierung

Um Devins Commits mit GPG zu signieren, konfigurieren Sie den Schlüssel in Ihrer Umgebung, damit er sitzungsübergreifend erhalten bleibt. Das Generieren des Schlüssels in einem Sitzungs-Terminal funktioniert nicht — jede Devin-Sitzung startet mit einer frischen Kopie des Maschinenabbilds, sodass alle während der Sitzung erstellten Schlüssel verworfen werden, wenn die Sitzung endet.

GPG-Signierung über die Umgebungskonfiguration erzeugt nur dann Verified-Commits, wenn Devin der Commit-Autor ist. GitHub verifiziert Signaturen anhand der Autor- Identität. In jedem Commit authoring-Modus, in dem der Autor der anfragende Nutzer ist (z. B. „Co-authored“, „User only“, „User as author, Devin as committer“), überschreibt Devin user.email jedoch pro Sitzung mit der jeweiligen E-Mail-Adresse des Nutzers — und diese stimmt nicht mit einem einzelnen gemeinsam genutzten GPG-Schlüssel überein. Setzen Sie den Commit authoring-Modus Ihrer Org auf „Devin only“ oder „Devin as author, user as committer“, bevor Sie sich auf dieses Setup verlassen.

Richten Sie dies auf der org-weiten Schicht ein (oder auf der Enterprise-Schicht, wenn alle Ihre Orgs dies benötigen), damit jedes Repo eine Konfiguration für signierte Commits erhält:

Erstellen Sie ein dediziertes GitHub-Nutzerkonto (oder wählen Sie eines aus), das sowohl die Commit-Autor-Identität als auch die Zugangsdaten besitzt, mit denen Devin pusht — z. B. devin@company.com. Wenn Sie für beides ein Konto verwenden, ist die Signatur-Einrichtung unkompliziert; bei zwei Konten verteilt sich die unten beschriebene Konfiguration auf beide.
Generieren Sie lokal einen GPG-Schlüssel mit der E-Mail-Adresse dieses Kontos als UID und folgen Sie dabei den Anweisungen von GitHub.
Laden Sie den öffentlichen Schlüssel in das GitHub-Konto hoch, dessen verifizierte E-Mail mit der GPG-UID übereinstimmt, unter GitHub Settings > SSH and GPG keys. GitHub verifiziert Signaturen anhand der Identität des Commit-Autors, nicht anhand der Identität, die pusht — der öffentliche Schlüssel muss auf dem Konto hinterlegt sein, dem die E-Mail in user.email gehört. (Wenn das dasselbe dedizierte Konto ist, mit dem Sie pushen, müssen Sie dies nur einmal tun.)
Exportieren Sie den privaten Schlüssel, kodieren Sie ihn mit Base64 und fügen Sie ihn (zusammen mit den passenden GIT_USER_NAME / GIT_USER_EMAIL) als Secrets in Settings > Secrets hinzu.
Importieren Sie in Ihrer org-weiten Umgebungskonfiguration den Schlüssel und aktivieren Sie die Signierung bei jedem Sitzungsstart. Das vollständige YAML finden Sie im Copy-paste-Beispiel für GPG-Commit-Signierung.

Die Committer-E-Mail (user.email) muss mit einer UID auf dem GPG-Schlüssel übereinstimmen, und dieselbe E-Mail muss als verifizierte E-Mail-Adresse im GitHub-Konto hinterlegt sein, in das Sie den öffentlichen Schlüssel hochgeladen haben. Wenn eine dieser drei Angaben nicht übereinstimmt, zeigt GitHub den Commit als Unverified an, auch wenn die Signatur selbst gültig ist.

Sicherheitsaspekte

Branchschutz: Wir empfehlen, Branchschutzregeln auf Ihrem Haupt-Branch zu aktivieren, um sicherzustellen, dass alle erforderlichen Prüfungen erfolgreich abgeschlossen sind, bevor Devin Änderungen zusammenführen kann.
Berechtigungen auf Organisationsebene: Devin verwendet die auf Organisationsebene gewährten Berechtigungen, nicht die Berechtigungen des einzelnen Benutzers, der eine Sitzung ausführt.
Einheitlicher Zugriff: Alle Benutzer mit Zugriff sowohl auf die GitHub- als auch auf die Devin-Organisation verfügen über dieselben Devin-Integrationsberechtigungen.
Repository-Erstellung: Devin kann in Ihrem GitHub-Konto keine neuen Repositories erstellen.

IP-Allowlisting

Wenn Ihre Organisation IP-Allowlisting für den Zugriff auf GitHub erfordert, fügen Sie die folgenden IP-Adressen hinzu:

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

Diese IP-Adressen können sich in zukünftigen Updates ändern. Wir empfehlen, unsere Release Notes auf etwaige Änderungen zu prüfen.

Fehlerbehebung: GitHub-Organisation ist mit der falschen Devin-Organisation verbunden

Wenn Ihre GitHub-Organisation bereits mit einer Devin-Organisation verbunden ist, auf die Sie keinen Zugriff haben, kann ein GitHub-Organisationsadministrator die bestehende Installation entfernen und sie unter einer anderen Devin-Organisation neu installieren.

Wir empfehlen, dies vor dem Entfernen der Installation mit dem Inhaber der aktuellen Devin-Organisation abzustimmen.

Rufen Sie github.com/settings/installations auf und klicken Sie neben Devin.ai Integration auf Configure. Wechseln Sie bei Bedarf über das Dropdown-Menü Go to settings page oben rechts in den richtigen GitHub-Organisationskontext.
Scrollen Sie auf der Installationsseite zum Abschnitt Danger zone und klicken Sie auf Uninstall, um die Devin.ai Integration aus der GitHub-Organisation zu entfernen.
Kehren Sie zu app.devin.ai zurück und laden Sie die Seite neu. Sie können die GitHub-Integration jetzt unter Ihrer Devin-Organisation neu installieren.

GitHub-Integration – FAQ

Kann ich mein persönliches GitHub-Konto mit dem Devin-Konto meiner Organisation verbinden?

Ja, Sie können entweder eine GitHub-Organisation oder ein persönliches GitHub-Konto mit Ihrer Devin-Organisation verbinden. Wir empfehlen jedoch, das Konto zu verbinden, das über die passenden Berechtigungen verfügt, damit Devin auf die Repositorys zugreifen kann, die Ihr Team benötigt.

Wie verarbeitet die GitHub-App die Authentifizierung von Nutzern?

Nur Nutzer, die Mitglieder der Organisation sind, die die GitHub-Integration installiert hat, können sie in ihren Devin-Sitzungen verwenden. Devin erhält Zugriff auf die GitHub-Integration basierend auf der Organisationszugehörigkeit des Nutzers.

Wie verwaltet und rotiert Devin Verschlüsselungsschlüssel?

Verschlüsselungsschlüssel werden von AWS KMS verwaltet und regelmäßig erneuert.

Loslegen

Grundlegende Richtlinien

Einführung in Devin

Arbeiten mit Devin

Produktleitfäden

Integrationen

Admin

Warum Devin mit GitHub integrieren?

Einrichten der Integration