Skip to main content

​
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, öffne Settings → Connections → 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.
  1. Öffnen Sie in Ihrem Devin-Konto Settings → Connections → GitHub und klicken Sie auf Add Connection.
Devin
  1. Wenn Sie noch nicht bei GitHub angemeldet sind, werden Sie zur Authentifizierung aufgefordert.
Devin
  1. Wählen Sie die GitHub-Organisation aus, die Sie mit Devin verbinden möchten.
Devin
  1. 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.
Devin
  1. Nach Abschluss der GitHub-Autorisierung werden Sie zu den Devin-Einstellungen weitergeleitet, wo Sie überprüfen können, dass die Integration aktiv ist.
Devin
Wir empfehlen, Branchschutzregeln 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.
Devin
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 automatisch Kommentare zu PRs, an denen seine Sitzungen arbeiten, solange die Sitzung nicht archiviert wurde. Wie Sie aus einem beliebigen PR eine neue Sitzung starten, erfahren Sie unter Devin über einen PR-Kommentar starten.

​
Devin über einen PR-Kommentar starten

Sie können Devin Aufgaben übergeben, ohne GitHub zu verlassen. Hinterlassen Sie in einem beliebigen offenen Pull Request in einem mit Devin verbundenen Repository einen Kommentar, der mit /devin beginnt, gefolgt von der gewünschten Aufgabe:
Devin startet eine neue Sitzung mit diesem Repository, nutzt den PR als Kontext (und übernimmt den PR, sofern sinnvoll) und antwortet im PR mit einem Link zur Sitzung. Voraussetzungen:
  • Anfang des Kommentars — der Befehl muss am Anfang des Kommentars stehen. Die Groß-/Kleinschreibung spielt keine Rolle, und er funktioniert sowohl in PR-Unterhaltungskommentaren als auch in Inline-Review-Kommentaren.
  • Nur offene PRs — Kommentare zu Issues oder zu geschlossenen bzw. gemergten PRs werden ignoriert.
  • Schreibzugriff — die kommentierende Person benötigt die Berechtigung write oder admin für das Repository.
  • Verknüpftes Konto — das GitHub-Konto der kommentierenden Person muss mit ihrem Devin-Konto verknüpft sein, und sie muss Member einer Devin-Organisation sein, die Zugriff auf das Repository und die Berechtigung zur Nutzung von Devin-Sitzungen hat.
Wenn bereits eine Devin-Sitzung an dem PR arbeitet, werden /devin-Kommentare an diese Sitzung gesendet, anstatt eine neue zu starten.

​
Nutzerverknüpfung

Die oben beschriebene Verbindung über die GitHub-App gilt organisationsweit. Darüber hinaus können einzelne Nutzer ihr eigenes GitHub-Konto mit Devin verknüpfen, damit Devin unter ihrer Identität handeln kann: Pull Requests, die Devin in ihren Sitzungen öffnet, werden ihnen als Autor zugeordnet, und Kommentare oder Reviews, die sie über Devin Review einreichen, erscheinen unter ihrem GitHub-Konto. So verknüpfen Sie ein persönliches GitHub-Konto:
  1. Öffnen Sie Settings > Connections in den Einstellungen Ihres persönlichen Kontos
  2. Suchen Sie die Zeile GitHub in der Liste der Konten
  3. Klicken Sie auf Link und schließen Sie die GitHub-Autorisierung ab
Um die Verknüpfung später zu entfernen, klicken Sie in derselben Zeile auf Unlink user. Devin widerruft dabei den OAuth-Token bei GitHub.
Die GitHub-Zeile erscheint nur, wenn Ihre Organisation über eine GitHub-Verbindung verfügt. Fehlt sie, prüfen Sie, ob Sie Mitglied einer Devin-Organisation sind, deren GitHub-Integration eingerichtet ist. Instanzen von GitHub Enterprise Server erscheinen als separate Zeilen GitHub Enterprise, die mit dem jeweiligen Host beschriftet sind, und werden auf dieselbe Weise verknüpft.
Damit Devin Pull Requests als der verknüpfte Nutzer öffnet, muss ein Admin zusätzlich Open PRs as unter Settings > Devin > Pull requests festlegen:
  • Devin: öffnet Pull Requests immer als Devin
  • User: öffnet als der Nutzer, sofern dessen Git-Konto verknüpft ist, andernfalls als Devin
  • User only: öffnet als der Nutzer und schlägt fehl, wenn dessen Git-Konto nicht verknüpft ist (bei Automatisierungen und Service-Benutzern wird weiterhin auf Devin zurückgegriffen)

​
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:
  1. Navigiere zu den Settings > GitHub Apps deiner GitHub-Organisation (z. B. https://github.com/organizations/<org_name>/settings/installations)
  2. Wähle Configure für die Devin.ai-Integration aus
  3. Wähle unter Repository access, ob du Zugriff auf alle Repositories gewähren oder bestimmte Repositories auswählen möchtest
  4. Klicke auf Save, um deine Änderungen zu übernehmen
Devin
Devin benötigt die folgenden Berechtigungen: Lesezugriff auf: Lese- und Schreibzugriff auf: 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. 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:
  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
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 Committer ist. GitHub verifiziert Signaturen anhand der Committer-E-Mail. In jedem Commit authoring-Modus, in dem der Committer der anfragende Nutzer ist („Co-authored (you + Devin)“, „You only“, „Devin as author, you as committer“), committet Devin jedoch mit der jeweiligen E-Mail-Adresse des Nutzers als Committer — und diese stimmt nicht mit einem einzelnen gemeinsam genutzten GPG-Schlüssel überein. Lassen Sie einen enterprise admin Commit authoring unter Enterprise Settings > Devin > Git commit attribution auf „Devin only“, „Co-authored (Devin + you)“ oder „You as author, Devin as committer“ setzen, bevor Sie sich auf dieses Setup verlassen. Diese unternehmensweite Einstellung überschreibt die persönliche Präferenz Git commit author jedes Nutzers; solange sie auf Per-user (Default) belassen wird, gilt die jeweils eigene Auswahl des Nutzers unter Settings > Preferences. Wenn Ihre Organisation nicht Teil eines Enterprise ist, gibt es keine org-weite Steuerung: Jeder Nutzer, der Devin-Sitzungen startet, muss seinen persönlichen Git commit author unter Settings > Preferences auf einen dieser Modi setzen.
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:
  1. 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.
  2. Generieren Sie lokal einen GPG-Schlüssel mit der E-Mail-Adresse dieses Kontos als UID und folgen Sie dabei den Anweisungen von GitHub.
  3. 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 Committers, 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.)
  4. 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 → Resources → Secrets hinzu.
  5. 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
  • 140.232.64.0/26
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.
  1. 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.
    GitHub-Settings-Kontext wechseln
  2. 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.
    Devin.ai Integration deinstallieren
  3. 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

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.
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.
Verschlüsselungsschlüssel werden von AWS KMS verwaltet und regelmäßig erneuert.