Einen PR prüfen und mergen

Diese Anleitung zeigt, wie du einen Pull Request prüfst und mergst.

Die PR-Arbeitsfläche öffnen

Geh in der Seitenleiste zu Pull Requests
Wähle einen PR aus der Liste

Ein PR öffnet sich als Arbeitsfläche mit Tabs. Fünf Tabs sind von Anfang an offen, in dieser Reihenfolge: Übersicht, Diff, Versionsverwaltung, Chat und Aktionen (CI-Checks, nach Workflow gruppiert). Review — zuerst der Fortschritt der Review-Pipeline, danach das veröffentlichte Artefakt mit der Befundleiste — gehört bewusst nicht dazu. Ein PR hat kein Review, bis jemand eines anfordert, deshalb öffnet ihn Ask AI. Ein Terminal, ein Editor für eine einzelne Datei, ein eingebetteter code-server und ein Browser in der App öffnen sich bei Bedarf. Tabs für die Bereitstellungsvorschau erscheinen automatisch, sobald auf dem PR eine Vorschau-URL erkannt wird. Dein Tab-Layout wird je PR gemerkt.

Der Tab Übersicht trägt die Metadaten des PR (Autor, Branch, Labels, Zugewiesene, Reaktionen, Commits, Check-Status) und die Aktionszeile: Aktualisieren, Review, Merge, in der IDE öffnen und ein Menü ⋯.

Den Diff lesen

Öffne den Tab Diff, um den ganzen Diff des PR auf einmal zu sehen, mit einem Dateibaum zum Springen zwischen den Dateien.

Die Einstellungsschaltfläche in der Diff-Werkzeugleiste schaltet zwischen Geteilt (nebeneinander) und Einheitlich um und schaltet Zeilenumbruch sowie Ligaturen der Code-Schriftart ein und aus.
Die Hunk-Kopfzeilen @@ sind ersetzt durch die Steuerelemente Show N lines und Show end of file, die beim Klick den umgebenden Kontext einblenden.
Mit j und k springst du von Datei zu Datei, mit c klappst du die fokussierte Datei zu oder auf, mit t stellst du die Seitenleiste wieder auf den Dateibaum, und mit ⌘F durchsuchst du den ganzen Diff (Enter und Shift+Enter gehen die Treffer durch).
Mit v markierst du die fokussierte Datei als angesehen, und der Cursor springt zur nächsten Datei. Auf GitHub speichert der Code-Host diesen Status, er folgt dir also zwischen den Clients. GitLab und Bitbucket haben keine solche API, dort merkt sich das nur dieses Gerät.

Ziehen mit der Maus im Code markiert Text bis auf die Spalte genau, und ⌘C kopiert den rohen Quelltext statt der dargestellten Diff-Markierungen.

Inline-Kommentare schreiben

Tippe auf den Rand einer Codezeile, um einen Composer an dieser Zeile zu öffnen, oder nutze die Schaltfläche + in der Dateikopfzeile für einen Kommentar auf Dateiebene
Schreib dein Feedback in Markdown
Schick ab

Auf GitHub und GitLab bietet der Composer zwei Wege zum Abschicken: Einzelnen Kommentar hinzufügen postet sofort, und Review starten oder Zur Review hinzufügen legt den Kommentar in eine ausstehende Review, die mit Genehmigen, Änderungen anfordern oder Kommentieren rausgeht. Bitbucket bündelt keine ausstehende Review, dort geht jedes Abschicken sofort raus. Ein sofortiger Post zeigt Veröffentlichen…, bis der Code-Host ihn bestätigt, und wechselt dann auf Synchronisiert. Schlägt er fehl, trägt der Thread den Fehler und lässt einen erneuten Versuch zu.

Nur der Text der Review ist ein Entwurf: er wird serverseitig für (Eigentümer, Repo, PR-Nummer) gespeichert, kurz nachdem du aufhörst zu tippen. Er übersteht ein Neuladen und folgt dir zwischen Desktop- und Web-Client.

Ein Review abschicken

Klicke in der Aktionszeile der Übersicht auf Review (ausgeblendet auf deinen eigenen PRs und auf einem geschlossenen oder zusammengeführten PR)
Schreib den Review-Text. Du kannst ein Bild anhängen, ein Emoji oder ein GIF einfügen und zwischen Schreiben und Vorschau wechseln
Klicke auf Änderungen anfordern, Kommentieren oder Genehmigen

Das Verdikt ist die Schaltfläche — einen eigenen Auswähler gibt es nicht. Nach Genehmigen heißt sie Genehmigt, nach Änderungen anfordern heißt sie Änderungen angefordert, und der Entwurf wird geleert. Ein Verdikt Kommentieren lässt die Beschriftung bei Review.

Mergen

Die Schaltfläche Merge erscheint, wenn du Schreibzugriff hast, der PR offen ist und kein Entwurf ist. Ihre Farbe ist ein Bereitschaftssignal aus den erforderlichen Genehmigungen und dem Check-Status (bereit / ausstehend / blockiert) — nur ein Hinweis. Der Review-Status schaltet die Schaltfläche nie aus. Durchgesetzt werden die Regeln von der eigenen Branch Protection des Code-Hosts.

Klicke auf Merge, um das Merge-Flyout zu öffnen
Wähle eine Merge-Methode: Squash and merge (die Vorgabe), Create a merge commit oder Rebase and merge. Bitbucket hat keinen echten Rebase-Merge, deshalb wird Rebase auf seine Fast-Forward-Strategie abgebildet und scheitert bei einem divergierten Branch
Bei Squash and merge und Create a merge commit bearbeitest du die vorausgefüllten Felder Commit title und Commit description. Rebase and merge nimmt keines von beiden und blendet beide Felder aus
Lies das Warnfeld — es nennt fehlschlagende Checks und ausstehende Reviews, hält dich aber nicht auf
Klicke im Flyout auf Merge, um zu bestätigen

Mergen ist endgültig: es schiebt Commits zum Code-Host, deshalb gibt es einen Bestätigungsschritt statt eines Eintrags im Rückgängig-Stapel. Danach wird der Cache des PR ungültig, der Status wechselt auf Zusammengeführt, und ein Ereignis PullRequestStatusChanged wird mit dem Status merged ausgelöst. Dieses Ereignis gibt den kurzlebigen Worktree von „Im Editor öffnen“ frei und startet zwei mitgelieferte Pipelines: Stale repository cleanup, die die veralteten Worktrees und Unterhaltungsordner des PR entfernt, und Release notes, die einen Changelog-Eintrag entwirft.

Den PR an Reviewer-Agenten übergeben

Das Menü ⋯ auf dem Tab Übersicht enthält Ask AI. Damit startet die mitgelieferte Pipeline pr_review für diesen PR. Der Eintrag erscheint nur, solange der PR offen ist. Siehe KI-gestützte Review nutzen dafür, was die Pipeline tut und wie du ihre Befunde veröffentlichst, und Review-Compute für das deterministische Modell aus Kohorten und Achsen.

Einen externen PR prüfen

Control Center importiert auch PRs, die Menschen außerhalb der App geöffnet haben. Der Ablauf oben ist derselbe. Externe PRs erkennt der PR-Polling-Dienst.