Gemini auf GitHub: PR-Reviews und Actions

Gemini kann Ihre Pull Requests automatisch reviewen. Es liest den Diff, kommentiert riskante Zeilen inline und postet eine Zusammenfassung, ausgelöst bei jedem Push in GitHub Actions oder Cloud Build. Damit wird Ihre CI-Pipeline zu einem First-Pass-Reviewer, der nie müde wird und nie die langweiligen Dateien überspringt.

In dieser Lektion bauen wir das von Anfang bis Ende auf. Sie sehen die offizielle Action, ein sauberes Workflow-YAML, die genauen Berechtigungen, die nötig sind, und die Hebel, mit denen es günstig und sicher bleibt.

Zwei Wege, Gemini auf einen PR anzusetzen

Es gibt zwei unterschiedliche Integrationswege, und wer sie verwechselt, verliert Zeit.

Gemini Code Assist for GitHub ist die verwaltete App. Sie installieren sie aus dem GitHub Marketplace in einem Repo oder einer Org. Sie reviewt PRs automatisch und reagiert auf /gemini-Befehle in Kommentaren (zum Beispiel /gemini review oder /gemini summary). Es gibt kein YAML und kein Key-Management. Fangen Sie hier an: Gemini Code Assist.

Die Run Gemini CLI Action ist der Do-it-yourself-Weg. Sie steuern den Workflow, das Modell, den Prompt und die einzelnen Schritte. Nutzen Sie ihn, wenn Sie eigene Checks brauchen, etwa einen Changelog-Eintrag erzwingen, eine Dependency blockieren oder prüfen, ob eine Migrationsdatei existiert. Das ist auch der Weg, wenn das Review in Ihrer bestehenden Cloud-Build-PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → laufen soll. Die Action heißt google-github-actions/run-gemini-cli.

Der Rest dieser Lektion behandelt den DIY-Weg, weil dort die erweiterte Kontrolle liegt.

Was "die CLI in CI" konkret bedeutet

Sie kennen die Gemini CLI bereits als interaktiven Terminal-Agenten. In CI läuft sie headless: Sie übergeben einen Prompt, sie kann Dateien lesen und Shell-Tools ausführen (etwa die gh CLI) und beendet sich danach. Die GitHub Action ist ein dünner Wrapper. Sie authentifiziert, übergibt der CLI einen Prompt und stellt die Tools bereit, die zum Posten von Kommentaren nötig sind.

Der minimale PR-Review-Workflow

Hier ist ein vollständiger Workflow. Er wird bei Pull Requests ausgelöst, gibt Gemini den Diff-Kontext und lässt Gemini über die GitHub CLI ein Review posten.

name: Gemini PR Review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Gemini review
        uses: google-github-actions/run-gemini-cli@v0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
        with:
          gemini_api_key: ${{ secrets.GEMINI_API_KEY }}
          gemini_model: gemini-3-flash
          prompt: |
            Review the diff for PR #${PR_NUMBER}.
            Run: gh pr diff ${PR_NUMBER}
            Focus on bugs, security issues, and missing error handling.
            Skip style nits. If the diff is clean, say so briefly.
            Post your review with:
            gh pr comment ${PR_NUMBER} --body "<your review>"

Achten Sie darauf, was hier fehlt. Es gibt kein riesiges eigenes Skript und keine manuellen APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen →-Aufrufe. Die Action authentifiziert die CLI, der Prompt sagt Gemini, was zu tun ist, und Gemini nutzt gh (auf GitHub-Runnern vorinstalliert), um den Diff zu lesen und zurückzuposten.

Die Action steht noch auf einem v0-Tag, Input-Namen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen sich also zwischen Releases ändern. Prüfen Sie im Action-README die aktuellen Inputs, bevor Sie das in Produktion übernehmen, und pinnen Sie eine konkrete Version, sobald es funktioniert.

Warum fetch-depth: 0

Ein Shallow Checkout (der Standard) holt nur den obersten Commit. gh pr diff braucht genug Historie, um den Diff gegen den Base-Branch zu berechnen. Mit der vollständigen Historie vermeiden Sie eine ganze Klasse von "leerer Diff"-Fehlern, die so aussehen, als hätte das Modell den Code ignoriert.

Berechtigungen: so wenig wie möglich, explizit benannt

Der permissions-Block ist die wichtigste Sicherheitskontrolle. GitHub gewährt dem GITHUB_TOKEN nur das, was Sie auflisten.

permissions:
  contents: read          # Code lesen
  pull-requests: write    # Review-Kommentare posten

Mehr braucht ein Review-Job nicht. Diese Berechtigungen fehlen bewusst:

• contents: write, weil der Job niemals Code pushen darf
• actions: write, weil ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → niemals andere Workflows ändern darf
• id-token: write, das nur für Workload Identity nötig ist (siehe unten)

Schützen Sie sich vor Forked PRs. Der pull_request-Trigger aus einem Fork erhält ein Read-only-TokenTokenEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen → und keinen Zugriff auf Ihre Secrets. Das ist korrekt und sicher. Wenn Sie auf pull_request_target umstellen, um Zugriff auf Secrets zu bekommen, läuft Ihr Workflow mit Schreibrechten gegen nicht vertrauenswürdigen Code aus dem Fork. Das ist ein bekannter Angriffsvektor. Bevorzugen Sie pull_request. Wenn ein Fork tatsächlich ein Review braucht, lassen Sie den Lauf vorher von einem Maintainer freigeben, über die GitHub-Einstellung "require approval for outside collaborators".

Authentifizierung: API-Key oder Vertex AI

Sie haben zwei Möglichkeiten, der Action Credentials zu geben, und die Wahl wirkt sich auf Abrechnung und Governance aus.

Gemini API-Key (wie oben gezeigt). Das ist die einfachste Option. Erstellen Sie einen Key in Google AI Studio und speichern Sie ihn als Repo-Secret GEMINI_API_KEY. Das passt für Einzelpersonen und kleine Teams. Die Abrechnung läuft über die Gemini API.

Vertex AI mit Workload Identity Federation. Das ist die Option für Unternehmen. Statt eines langlebigen Keys tauscht der Workflow sein GitHub-OIDC-Token gegen kurzlebige Google-Cloud-Credentials, es gibt also kein Secret, das leaken kann.

Für die Einrichtung fügen Sie id-token: write zu den Berechtigungen hinzu und konfigurieren den Schritt google-github-actions/auth. Das Review läuft dann gegen Vertex AI. Es landet in Cloud-Projekt, IAM, Quotas und Audit-Logging Ihrer Org. Das ist die Antwort, wenn die Security fragt: "Wohin geht unser Code und wer kann ihn sehen?"

In der Praxis sind Keys schneller für den Einstieg. Auf Vertex AI standardisieren Sie, sobald mehr als ein paar Leute vom Review abhängen.

Kosten im Griff behalten

Automatisierte Reviews laufen bei jedem Push. Ohne Limits kann ein mitteilsamer Contributor mit zehn Force-Pushes zehn vollständige Reviews auslösen. Drei Hebel steuern die Kosten.

Die passende Modellstufe wählen

Nutzen Sie Gemini 3 Flash für Routine-PR-Reviews. Das ist die schnelle, günstige Stufe, und sie findet zuverlässig fehlende Null-Checks, offensichtliche Injection-Risiken und fehlendes Error Handling. Heben Sie Gemini 3 Pro für Änderungen auf, die tieferes Reasoning über mehrere Dateien brauchen, etwa ein Architektur-Refactoring oder einen kniffligen Concurrency-Fix.

Ein gängiges Muster: standardmäßig Flash und ein zweiter Workflow, der das Review mit Pro wiederholt, wenn ein Maintainer das Label deep-review setzt.

Ältere Workflows pinnen oft noch gemini-2.5-flash. Google nimmt ältere Modellversionen nach einem veröffentlichten Zeitplan außer Betrieb. Prüfen Sie daher die Gemini-Modellseite und aktualisieren Sie den Modell-String, bevor ein gepinntes Modell nicht mehr antwortet und Ihr Check stillschweigend fehlschlägt.

Überholte Läufe abbrechen

Wenn jemand dreimal in einer Minute pusht, reviewen Sie nur den letzten Stand. Fügen Sie eine Concurrency-Gruppe hinzu:

concurrency:
  group: gemini-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

Bei aktiven PRs kann allein das die Ausgaben drastisch senken.

Eingrenzen, was das Modell liest

Gemini kommt gut mit langem Kontext zurecht, aber dass es ein ganzes Repo lesen kann, heißt nicht, dass jedes Review das tun sollte. Ein komplettes Monorepo in jedes Review zu geben, ist langsam und teuer. Begrenzen Sie den Prompt auf den Diff (gh pr diff). Bei großen Diffs sagen Sie dem Modell, es soll sich auf die Dateien mit dem höchsten Risiko konzentrieren (Auth, Migrationen, Payment-Logik), statt jede geänderte Zeile zu kommentieren. Sie können im Prompt auch angeben, dass generierte Dateien und Lockfiles übersprungen werden.

Über das Review hinaus: Labels, Triage und Gated Checks

Sobald die Action eingerichtet ist, ist das PR-Review nur noch ein Prompt unter vielen. Mit demselben Setup automatisieren Sie die mühsamen Randaufgaben bei der Pflege eines Repos.

Issues automatisch triagieren. Ein separater Workflow, ausgelöst durch issues: [opened], kann Gemini ein neues Issue lesen und Labels setzen lassen (bug, docs, feature). Er kann auch einen Kommentar der Art "Das brauchen wir, um das zu reproduzieren" posten. Geben Sie diesem Workflow issues: write und sonst nichts.

Gated Custom Checks. Weil die CLI Shell-Tools ausführen kann, können Sie Projektregeln durchsetzen lassen, die ein Linter schwer abbilden kann. Eine Beispielzeile im Prompt: "If this PR changes any file under db/migrations/, verify a matching rollback file exists. If not, post a comment and exit with code 1." Ein Exit-Code ungleich null lässt den Check fehlschlagen. Das blockiert den Merge, wenn Sie ihn in der Branch Protection als Required Status Check festlegen.

Geplante Wartung. Ein schedule-Trigger kann Gemini jede Nacht laufen lassen, um veraltete PRs zusammenzufassen oder Dependencies zu markieren, die abgedriftet sind. Hier zahlt sich das agentische Design der CLI aus. Sie liest den Zustand, denkt nach und handelt in einem Schritt.

Das Review nützlich halten statt laut

Der schnellste Weg, einen Bot ignoriert zu bekommen: ihn alles kommentieren lassen. Zwei Regeln halten das Signal hoch.

Erstens: Sagen Sie ihm, was es überspringen soll. Stil und Formatierung gehören zu Ihrem Linter und Formatter, nicht zu Gemini. Schreiben Sie "do not comment on formatting, import ordering, or naming style" direkt in den Prompt.

Zweitens: Kennzeichnen Sie die Ausgabe. Ein First-Pass-Review ist ein erster Durchgang, nicht das letzte Wort. Eine einzeilige Überschrift wie "Automated review by Gemini 3 Flash. A human still owns approval." setzt Erwartungen und verhindert, dass das Review mit einer Freigabe verwechselt wird.

Ein Prompt, der gut altert

Legen Sie die Review-Anweisungen als Datei im Repo ab (zum Beispiel .gemini/review-prompt.md) und lassen Sie den Workflow sie einlesen, statt einen langen Prompt inline ins YAML zu schreiben. Das hat zwei Vorteile:

• Der Prompt ist versioniert und lässt sich reviewen wie jeder andere Code.
• Verschiedene Repos können ihre eigenen Schwerpunkte setzen. Ein sicherheitskritischer Service kann strengere Checks verlangen als ein internes Dashboard.

Die Action akzeptiert außerdem einen Settings-Input für die CLI-Konfiguration, damit bleibt Ihr Workflow-YAML kurz.

Einbindung in Cloud Build

Wenn Ihre Org CI in Google Cloud statt auf GitHub-Runnern betreibt, läuft dieselbe Gemini CLI als Cloud-Build-Schritt. Sie lösen den Build über ein GitHub-PR-Event aus, führen gemini mit dem Prompt in einem Schritt aus und posten mit gh zurück.

Der Vorteil: Die Authentifizierung gegenüber Vertex AI ist nativ. Der Service Account des Builds hat bereits eine Google-Cloud-Identität, es gibt also keine OIDC-Federation zu konfigurieren und keinen Key zu speichern. Für regulierte Umgebungen, in denen Code Ihren Cloud-Perimeter nicht verlassen darf, ist das das sauberste Setup.

Key Takeaways

• Nutzen Sie die verwaltete Gemini Code Assist GitHub App für Reviews ohne Konfiguration. Nutzen Sie die run-gemini-cli Action, wenn Sie eigene Checks, eigene Prompts oder eine Cloud-Build-Integration brauchen.
• Ein Reviewer braucht nur contents: read und pull-requests: write. Gewähren Sie nie Schreibzugriff auf Code und vermeiden Sie pull_request_target bei nicht vertrauenswürdigen Forks.
• Standardmäßig Gemini 3 Flash, bei Bedarf Eskalation auf Gemini 3 Pro. Ersetzen Sie gepinnte 2.5-Modell-Strings, bevor sie außer Betrieb genommen werden.
• Fügen Sie eine concurrency-Gruppe mit cancel-in-progress hinzu und begrenzen Sie den Prompt auf den Diff, damit die Kosten bei aktiven PRs planbar bleiben.
• Starten Sie mit einem AI-Studio-API-Key. Wechseln Sie zu Vertex AI mit Workload Identity Federation, sobald Fragen zu Audit und Data ResidencyData ResidencyDie Anforderung, Daten physisch in einem bestimmten Land oder einer Region zu speichern und zu verarbeiten, oft aus rechtlichen oder vertraglichen Gründen.Vollständige Definition ansehen → aufkommen.
• Legen Sie den Review-Prompt im Repo ab und sagen Sie dem Modell, was es überspringen soll. Kennzeichnen Sie jeden Kommentar als automatisiert, damit der Merge bei einem Menschen bleibt.