Mit Gemini CLI eine Repository-Änderung prüfen und umsetzen

Starte Gemini CLI im Checkout, den du ändern möchtest. Wähle einen kleinen Fehler mit beobachtbarem Ergebnis und halte unabhängige lokale Änderungen aus dieser Übung heraus.

Das Beispiel ist eine zu lange Wartezeit: Der erste Wiederholungsversuch wartet zwei Sekunden, obwohl eine verlangt ist. Der Aufrufer zählt ab eins. Verwende die echten Tests deines Repositorys und einen passenden Branch oder Worktree aus deinem normalen Entwicklungsablauf.

Kontrolliere den Projektkontext

Halte Quellordner, Prüfbefehle, wichtige Verträge und den Umgang mit ungeprüften Ergebnissen in GEMINI.md fest. /memory show zeigt die geladenen Vorgaben. Nach Änderungen lädt /memory reload die Kontextdateien erneut.

Für ein kleines JavaScript-Paket könnten die Regeln so aussehen:

# Entwicklungskontext

- Wiederholungsversuche werden ab eins gezählt.
- Die Obergrenze von dreißig Sekunden bleibt bestehen.
- Vor dem Testlauf den Prüfbefehl in package.json nachsehen.
- Den ursprünglichen Fehler prüfen und Befehl sowie Exit-Status melden.

Dass die Datei existiert, beweist noch nicht, dass sie geladen wurde. Vergleiche die Speicheranzeige mit den erwarteten Regeln.

Plane die Änderung interaktiv

Starte mit gemini --approval-mode=plan oder verwende /plan in der interaktiven Sitzung. Plan Mode begrenzt Aktionen normalerweise auf Recherche und Planungsdateien; eigene Richtlinien können diese Grenze verändern.

Gib eine konkrete Aufgabe:

Finde heraus, warum der erste Wiederholungsversuch zwei Sekunden wartet. Prüfe die Zählweise des Aufrufers, benenne die kleinste Korrektur und plane Tests für 1, 2 und 6. Behalte die Obergrenze bei. Zeige betroffene Dateien und offene Entscheidungen vor der Implementierung.

Prüfe den tatsächlichen Vorschlag. Er soll erklären, ob Formel oder Aufrufer falsch liegt und welcher Beleg das entscheidet. Gib die konkrete Umsetzung frei, wenn sie zur Aufgabe passt.

Für Automatisierung gilt die separate programmgesteuerte Anleitung (Englisch). Headless-Planung hat andere Übergänge; diese interaktive Abnahmefolge ist kein menschlicher Freigabepunkt in einem unbeaufsichtigten Befehl.

Prüfe im richtigen Arbeitsverzeichnis

Lass die vereinbarte Änderung umsetzen, lies den Diff und führe den gezielten Test aus. Danach folgen die relevanten Repository-Prüfungen. Notiere Checkout und Revision, auf denen die Ergebnisse entstanden sind.

Für Math.min(1000 * 2 ** (attempt - 1), 30000) ergeben sich eine, zwei und dreißig Sekunden. Ungültige Versuche brauchen einen ausdrücklichen Vertrag; der Agent soll ihn nicht beiläufig festlegen.

Was schiefgeht

Die Sitzung kann im falschen Ordner starten, veraltete Vorgaben laden oder ohne Aufruferprüfung einen Patch vorschlagen. Ein Plan kann außerdem unnötig viel Aufräumarbeit enthalten.

Kläre zunächst Verzeichnis und Belege. Prüfe zusätzlichen Umfang vor der Ausführung und verwende die Berechtigungs- und Integrationsregeln des Projekts.

So prüfst du das Ergebnis

Der Originalcode muss beim Test des ersten Versuchs scheitern, der neue Code bestehen. Kontrolliere, dass Obergrenze und Wiederholungszahl unverändert sind. Prüfe, ob der gemeldete Befehl im Checkout mit diesem Diff lief.

Betrifft die Änderung eine Bedienung, probiere sie selbst aus. Fehlgeschlagene Prüfungen und offene Vertragsfragen gehören zum Review.