Deinen ersten Pull Request prüfen

Was du baust

Am Ende dieses Tutorials hast du:

• Einen Pull Request in der PR-Arbeitsfläche von Control Center geöffnet
• Seinen Diff gelesen und einen Inline-Kommentar hinterlassen
• Ein Review-Verdikt abgeschickt
• Den PR gemergt

Voraussetzungen: Deinen ersten Agenten starten ist abgeschlossen, und in einem Repo, das in diesem Arbeitsbereich registriert ist, liegt ein offener Pull Request. Für die Review-Schritte nimm einen PR, den du nicht selbst geöffnet hast — die Schaltfläche Review ist auf deinen eigenen PRs ausgeblendet. Mergen funktioniert weiter auf einem PR, den du selbst erstellt hast.

Schritt 1: Den Pull Request öffnen

1. Klicke in der Seitenleiste auf Pull Requests
2. Such deinen PR und klicke ihn an

Kontrollpunkt. Der PR öffnet sich als Arbeitsfläche mit Tabs — Übersicht, Diff, Versionsverwaltung, Chat, Aktionen — mit Fokus auf Übersicht: Titel und Aktionen, Beschreibung und Aktivitätsverlauf sowie eine Seitenleiste mit Status, Reviewern, Zugewiesenen, Prüfungen und geänderten Dateien. Ein Klick auf eine Datei dort springt zu ihr im Tab Diff. Der Tab PR-Review ist erst offen, wenn jemand ein KI-Review anfordert.

Leere Warteschlange mit der Aufforderung „GitHub verbinden“

Dieser Zustand heißt: der Server hat kein GitHub-Token — dein Client hält nie eines. Hinterlege eines unter Einstellungen → Arbeitsbereich → Profil und Identität → Code-Hosting und aktualisiere dann die Liste.

Schritt 2: Den Diff lesen

Öffne den Tab Diff. Links liegt ein einklappbarer Dateibaum, und die Leiste über dem Diff trägt eine Auswahl für den Commit-Bereich — damit grenzt du den Diff auf einen Commit oder eine Spanne davon ein — dazu die Dateianzahl und die laufenden Hinzufügungen und Löschungen.

Die Einstellungsschaltfläche in der Diff-Werkzeugleiste steuert die Darstellung:

• Ansicht Geteilt oder Einheitlich
• Zeilenumbruch oder lange Zeilen scrollen
• Ligaturen der Code-Schriftart

Markiere eine Datei als angesehen, um deinen Fortschritt in einem großen Diff zu verfolgen. Die Tastatursteuerung steht unter Tastenkürzel.

Schritt 3: Einen Inline-Kommentar hinterlassen

1. Fahre über eine Zeile im Diff — im Rand erscheint eine kleine +-Pille
2. Klicke sie an, um diese Zeile zu kommentieren, oder zieh sie zuerst senkrecht, um einen Bereich zu markieren
3. Tippe dein Feedback. Der Composer bietet zwei Wege zum Abschicken:
   • Review starten (oder Zur Review hinzufügen, wenn schon eine Review läuft) legt den Kommentar zurück. Der Thread zeigt Ausstehende Review, bis du in Schritt 4 ein Verdikt abschickst.
   • Einzelnen Kommentar hinzufügen postet ihn sofort auf GitHub. Der Thread zeigt Veröffentlichen…, dann Synchronisiert, und bietet einen erneuten Versuch, wenn das Posten fehlschlägt.

Für dieses Tutorial nimm Review starten, damit der Kommentar zusammen mit dem Verdikt rausgeht.

Ein zurückgestellter Kommentar ist noch nicht auf GitHub

Review starten / Zur Review hinzufügen halten den Kommentar lokal, bis du ein Verdikt abschickst. Nur Einzelnen Kommentar hinzufügen postet sofort. Der Review-Text, den du in Schritt 4 schreibst, ist ein eigener Entwurf.

Schritt 4: Ein Review abschicken

1. Klicke in der Aktionszeile der Übersicht auf Review — dieselbe Schaltfläche sitzt auch in der Werkzeugleiste des Tabs Diff. Sie ist ausgeblendet auf PRs, die du selbst erstellt hast, und auf einem geschlossenen oder zusammengeführten PR.
2. Schreib eine Zusammenfassung im Composer. Sie wird automatisch als Entwurf gespeichert, du kannst das Overlay also schließen und später zurückkommen.
3. Wähle ein Verdikt:
   • Änderungen anfordern
   • Kommentieren
   • Genehmigen

Das Verdikt ist die Schaltfläche. Nach Genehmigen oder Änderungen anfordern beschriftet sie sich neu mit Genehmigt bzw. Änderungen angefordert. Ein Verdikt Kommentieren lässt die Beschriftung bei Review.

Kontrollpunkt. Die Schaltfläche zeigt „Genehmigt“ oder „Änderungen angefordert“, wenn du eines von beiden gewählt hast.

Schritt 5: Mergen

Die Schaltfläche Merge ist da, sobald GitHub den PR als mergebar meldet — sie hängt nicht an deiner eigenen Genehmigung. Ihre Farbe zeigt die Bereitschaft, nicht die Berechtigung: primär, wenn die erforderlichen Genehmigungen und Prüfungen grün sind, sekundär, solange eine Prüfung noch läuft, und destruktiv, wenn ein angeforderter Reviewer noch nicht genehmigt hat oder eine Prüfung fehlschlägt.

1. Klicke auf Merge
2. Wähle eine Methode: Squash and merge, Create a merge commit oder Rebase and merge
3. Bei den ersten beiden bearbeitest du den vorausgefüllten Commit-Titel und die Nachricht
4. Bestätige

Offene Probleme — „Prüfungen fehlgeschlagen“, „Some reviews are pending“ — stehen im Flyout, bevor du bestätigst.

Mergen lässt sich nicht rückgängig machen

Mergen schiebt Commits zu GitHub. Es landet nie im Rückgängig-Stapel von Control Center und lässt sich von hier nicht rückgängig machen.

Nach dem Merge feuert ein Domain-Ereignis PrMerged; Analysen und Benachrichtigungen verbrauchen es. Siehe Domain-Ereignisse dafür, was sonst noch zuhört.

Mit KI prüfen

Control Center kann eine Reviewer-Pipeline auf einen offenen PR legen, aber nur wenn du danach fragst: die Vorlage pr_review hat einen manuellen Trigger und sonst nichts.

1. Öffne in der Aktionszeile der Übersicht das Menü ⋯ und wähle Ask AI. Control Center startet den Lauf und öffnet den Tab PR-Review, damit du den Spezialisten bei der Arbeit zusehen kannst.
2. Reviewer-Agenten schreiben ihre Befunde als Review-Knoten in den Bereich des PR; ein letzter Schritt fasst sie zu einem Bericht zusammen.

Die Pipeline postet absichtlich nicht auf GitHub — sie endet nach dem Zusammenfassen. Veröffentlichen ist ein eigener Schritt, den du selbst machst, mit der Schaltfläche Auf GitHub veröffentlichen auf dem Tab PR-Review. Siehe KI-gestützte Review nutzen.

Rückblick

Du hast einen PR in der Arbeitsfläche geöffnet, den Diff mit Syntaxhervorhebung gelesen, einen Inline-Kommentar hinterlassen, ein Verdikt abgeschickt und gemergt — ohne die App zu verlassen.

Als Nächstes: Deine erste Pipeline bauen, um mehrstufige Abläufe zu automatisieren.