PR のレビューとマージ

このガイドでは、プルリクエストをレビューしてマージする方法を説明します。

PR ワークベンチを開く

サイドバーの プルリクエスト に移動します
一覧から PR を選択します

PR は単一のページではなく、タブ式のワークベンチとして開きます。既定では 5 つのタブがこの順に開きます: 概要、差分、ソース管理、チャット、操作（ワークフローごとにまとめられた CI チェック）。レビュー — レビューパイプラインの進行状況と、それが公開した成果物を指摘リストとともに示すタブ — は意図的にこの中に入っていません。PR は誰かがレビューを依頼するまでレビューを持たないため、AIに質問 がこれを開きます。ターミナル、単一ファイルのエディター、埋め込みの code-server、アプリ内ブラウザーはオンデマンドで開きます。PR でプレビュー URL が検出されると、デプロイプレビューのタブが自動的に挿入されます。タブのレイアウトは PR ごとに記憶されます。

概要タブには、PR のメタデータ（作成者、ブランチ、ラベル、担当者、リアクション、コミット、チェックステータス）と、アクション行（更新、レビュー、マージ、IDE で開く、⋯ オーバーフローメニュー）が表示されます。

差分を読む

差分タブを開くと、PR 全体の差分を一度に表示でき、ファイル間を移動するためのファイルツリーも表示されます。

差分ツールバーの設定ボタンで、分割（左右並置）ビューと統合ビューを切り替え、行の折り返しとコードフォントのリガチャをオン／オフできます。
@@ のハンクヘッダーは、Show N lines / Show end of file の操作に置き換えられ、クリックすると周囲のコンテキストが挿入されます。
j / k でファイル間を移動し、c でフォーカス中のファイルを折りたたむか展開し、t でサイドバーをファイルツリーに戻し、⌘F で差分全体を検索します（Enter / Shift+Enter で一致箇所をたどります）。
v を押すとフォーカス中のファイルが閲覧済みになり、カーソルは次のファイルへ進みます。GitHub では閲覧済みの状態はフォージ側に保存されるため、クライアント間で引き継がれます。GitLab と Bitbucket にはそのような API がないため、そこではこのデバイスにのみ記憶されます。

コード領域をマウスでドラッグすると、正確な桁までテキストを選択でき、⌘C はレンダリングされた差分マーカーではなく生のソースをコピーします。

インラインコメントを残す

コード行のガターをタップすると、その行にアンカーされたコンポーザーが開きます。ファイル単位のコメントには、ファイルヘッダーの + ボタンを使います
フィードバックは Markdown で書きます
送信します

GitHub と GitLab では、コンポーザーは 2 つの送信方法を用意します。単一のコメントを追加 はすぐに投稿し、レビューを開始 / レビューに追加 はコメントを保留中のレビューに積み、そのレビューは承認、変更をリクエスト、コメント のいずれかで送信されます。Bitbucket には保留レビューのバッチ処理がないため、そこではどの送信もすぐに投稿されます。即時投稿は、フォージが確認するまで保留状態を示し、その後「同期済み」に変わります。投稿に失敗すると、スレッドにエラーが表示され、再試行できます。

下書きになるのはレビューの_本文_だけです。入力が止まってから少し後に (owner, repo, PR number) をキーにサーバー側へ保存されるため、再読み込みしても残り、デスクトップと Web のクライアント間で引き継がれます。

レビューを送信する

概要のアクション行で レビュー を押します（自分の PR と、クローズ済みまたはマージ済みの PR では非表示になります）
レビューの本文を書きます。画像の添付、絵文字や GIF の挿入、作成とプレビューの切り替えができます
変更をリクエスト、コメント、承認のいずれかを押します

判定は_ボタンそのもの_です — 別個の判定ピッカーはありません。承認または 変更をリクエスト の後、ボタンは 承認済み または 変更リクエスト に表示が変わり、下書きの本文はクリアされます。コメント の判定では、ボタンは レビュー の表示のままです。

マージ

マージ ボタンは、書き込み権限があり、PR がオープンで下書きでないときに表示されます。その色は、必須の承認とチェック状態（ready / pending / blocked）から導かれる準備状況のシグナルです — あくまで参考情報です。ボタンがレビュー状態によって無効化されることはありません。ルールを強制するのはフォージ自身のブランチ保護です。

マージ を押すとマージのフライアウトが開きます
マージ方法を選びます: squash、merge commit、rebase（既定は squash）。Bitbucket には真の rebase マージがないため、rebase はその fast-forward 戦略に対応付けられ、分岐したブランチでは失敗します
squash と merge commit では、あらかじめ入力されたコミットのタイトルと説明を編集します。rebase はどちらも受け付けず、両方のフィールドを非表示にします
警告パネルを読みます — 失敗しているチェックと保留中のレビューが示されますが、操作はブロックされません
フライアウトのマージボタンを押して確定します

マージは取り消せません: コミットをフォージにプッシュするため、取り消しエントリではなく確認ステップが設けられています。マージ後は PR のキャッシュが無効化され、ステータスが マージ済み に変わり、PullRequestStatusChanged イベントがステータス merged で発火します。このイベントは一時的な「エディターで開く」ワークツリーを解放し、2 つのシード済みパイプラインを開始します: Stale repository cleanup（PR の古いワークツリーと会話フォルダーを削除します）と Release notes（変更履歴のエントリを起草します）。

PR をレビュアーエージェントに引き渡す

概要タブの ⋯ オーバーフローメニューに AIに質問 があり、この PR に対してシード済みの pr_review パイプラインを開始します。これは PR がオープンの間だけ表示されます。パイプラインが何をするか、その指摘をどう公開するかは AI レビューを使うを参照し、決定論的なコホートと軸のモデルはレビューコンピュートを参照してください。

外部 PR をレビューする

Control Center は、アプリの外部で人間が開いた PR もインポートします。上記のレビューの流れは同じです。外部 PR は PR ポーリングサービスによって検出されます。