glab-mr

glab mr

GitLab のマージリクエストを作成、表示、管理します。

リベースの完了とイシューブランチ

mr rebase と mr merge --rebase は、キューに追加されたサーバー側のリベースが目に見える形で完了するまで待機します。初期状態の rebase_in_progress=false を成功とみなすことはありません。ポーリングは1秒間隔で最大300回まで行われ、キャンセルにも対応します。リベースでエラーまたはタイムアウトが発生した場合、マージは中止されます。承認済みの再試行を行う前に、サーバーの状態を確認してください。リベースによってヘッド SHA が変わるため、--sha と --rebase は併用できません。また、--squash と --rebase も併用できません。これらのコマンドはブランチや MR を変更するため、対象を正確に指定した承認が必要です。

mr for と mr create --related-issue は、HTTP 400 の名前または階層の衝突が発生した場合に限り、ブランチの作成を再試行し、-1 から -100 までのサフィックスを試します。認証、権限、無効な参照、ネットワーク障害、および無関係なエラーが発生した場合は、ただちに停止します。ブランチを繰り返し作成したり、すべての失敗を再試行したりせず、元のエラーを調査してください。まず、イシュー、プロジェクト、ベースブランチ、および予定している変更内容を確認してください。

別のリポジトリで解決または再オープンする

--repo を指定した場合、mr note resolve と mr note reopen では、ディスカッション ID の前に MR を明示する必要があります。

glab mr note resolve 123 abc12345 --repo group/project
glab mr note reopen 123 abc12345 --repo group/project

ディスカッションには、完全な ID、8文字以上の一意なプレフィックス、または数値のノート ID を指定できます。--repo を指定せず MR を省略した場合は、現在のブランチが使用されます。バイナリの使用方法の行にはオペランドの順序に一貫性がありませんが、例と実装に従い、最初に MR、次にディスカッションを指定してください。ディスカッションの状態を変更する前に、対象を確認してください。

チェックアウト、作成、選択

glab mr checkout 123 --worktree ../review-mr-123 は、別のワークツリーに MR をフェッチしてチェックアウトします。そのパスを再利用すると、既存のワークツリーが更新されます。ブランチをチェックアウトできるワークツリーは1つだけです。必要に応じて、別のローカル名には --branch を指定してください。分岐やリセットの確認には注意してください。ワークツリーを分離しても、コミットやローカルの変更を破棄する許可にはなりません。一致するリモート経由でフェッチすると、追跡参照が作成されます。

mr create --fill はコミットからタイトルと説明を導き出し、--push が明示的に設定されていない場合はプッシュをデフォルトで行います。プッシュを抑止するには glab mr create --fill --push=false を使用してください。これは引き続き MR を作成するため、ドライランではありません。ソースブランチがすでにリモートで利用可能であることを確認してください。ドラフトとして作成すると、2つ目の Draft: プレフィックスが追加されるのを防げます。

glab mr update feature-branch --state opened --ready は、ブランチの検索対象をオープン中の MR に限定します。指定できる状態は opened、closed、merged、locked、any（デフォルト）です。ID と URL にはこの選択フィルターが適用されません。--state 自体は MR の状態を変更しません。

担当者が1人だけでレビュアーがいない場合、またはレビュアーが1人だけで担当者がいない場合のリストフィルターでは、サーバー側の順序が維持されます。複数ユーザーを組み合わせた結果にも同じ順序が保証されると考えないでください。mr view では、人が読みやすい形式で利用可能な実績時間と見積もり時間が表示されます。機械処理には JSON を使用してください。

テンプレートの選択

create --template では、単独の名前（任意で .md を付加）を指定すると、リポジトリの .gitlab/merge_request_templates/ ディレクトリ内で検索されます。絶対パス、または区切り文字を含むパスは直接読み込まれます。相対パスは現在のディレクトリを基準とし、~/ も使用できます。現在のディレクトリにあるファイルには、単独のテンプレート名ではなく ./template.md を使用してください。テンプレートディレクトリが存在しない場合、テンプレートはありません。その他のディレクトリ一覧取得エラーは表示されるため、再試行する前に修正してください。投稿する前にファイルの内容を読み、承認してください。--description-file と --template は引き続き併用できません。

クイックスタート

# Create MR from current branch
glab mr create --fill

# Create or update with a multi-line description from a file
glab mr create --title "Fix login bug" --description-file description.md
glab mr update 123 --description-file description.md

# Attach local files to a description
glab mr create --title "Fix login bug" --description "Before and after:" \
  --attach ./before.png --attach ./after.png
glab mr update 123 --attach ./latest.png

# List my MRs
glab mr list --assignee=@me

# Review an MR
glab mr checkout 123
glab mr diff
glab mr approve

# Merge an MR
glab mr merge 123 --when-pipeline-succeeds --remove-source-branch

パッチを自動処理する場合は、glab mr diff --raw を使用してください。通常のレンダリング済み差分は人が読むことを目的としており、--raw は標準的な unified diff ヘッダーを含む、変更されていない Git パッチを返します。

一般的なワークフロー

MR の作成

現在のブランチから：

glab mr create --fill --label bugfix --assignee @reviewer

# Create now, merge automatically when checks pass
glab mr create --fill --auto-merge

# Start from an MR template file when your project uses one
glab mr create --fill --template .gitlab/merge_request_templates/default.md

一度限りの複数行の説明には、--description-file <path> または標準入力用の --description-file - を使用します。--description とは併用できません。また、作成時には --template とも併用できません。内容が - のみのファイルは拒否されます。これは --description - が「エディターを開く」という意味だからです。

実験的な --attach <path> を繰り返し使用すると、ファイルをアップロードし、GitLab が提供する Markdown 形式の参照を説明に追加できます。--attach - は標準入力からファイルを 1 つ読み込み、--description-file - と標準入力を共有できません。更新時、置き換え用の説明を指定しない限り、添付ファイルは既存の説明に追加されます。フォークからのマージリクエストでは、mr create は添付ファイルをターゲットプロジェクトにアップロードするため、参照先を解決できます。

非対話型の環境では、明示的に --title を指定すれば十分です。glab は TTY や --description を必須とせず、説明が空の状態で MR を作成できます。対話型のターミナルでは、説明またはテンプレートが指定されていない場合、引き続き入力を求められます。再現性のある自動化を行うには、--yes と、ソース／ターゲット／リポジトリの各セレクターを明示的に指定してください。

GLAB_NO_PROMPT=1 glab mr create \
  --title "Fix login timeout" \
  --source-branch fix/login-timeout \
  --target-branch main \
  --yes

ローカルの Git チェックアウトがない場合：

glab mr create は、リモートに依存するすべての入力をフラグで指定すれば、Git リポジトリの外でも MR を作成できます。ソースブランチは、選択したソースプロジェクトにすでに存在している必要があります。ローカルリポジトリの状態が必要になるため、--push、--fill、--template は使用しないでください。

glab mr create \
  --repo group/project \
  --source-branch feature-branch \
  --target-branch main \
  --title "Add feature" \
  --description "Details..." \
  --yes

# Fork source into an upstream target
glab mr create \
  --repo upstream/project \
  --head your-namespace/project \
  --source-branch feature-branch \
  --target-branch main \
  --title "Add feature" \
  --description "Details..." \
  --yes

イシューから：

glab mr for 456  # Creates MR linked to issue #456

ドラフト MR：

glab mr create --draft --title "WIP: Feature X"

レビューワークフロー

1. 保留中のレビューを一覧表示する：

   glab mr list --reviewer=@me --state=opened
   

2. チェックアウトしてテストする：

   glab mr checkout 123
   npm test
   

3. フィードバックを残す：

   # Forward command surface for new MR comments/discussions
   glab mr note create 123 -m "Looks good, one question about the cache logic"
   
   # Automation/status update that should not create a resolvable thread
   glab mr note create 123 -m "Build status: green" --resolvable=false
   
   # Reply inside an existing discussion thread
   glab mr note create 123 --reply abc12345 -m "Good catch — updated"
   
   # Internal note visible only to project members
   glab mr note create 123 --internal -m "Rotating the leaked token now."
   
   # Native diff comments on the latest MR version
   glab mr note create 123 --file src/cache.ts --line 42 -m "Please extract this branch"
   glab mr note create 123 --file src/cache.ts --old-line 17 -m "Why was this removed?"
   
   # Stage comments in a private pending review, then publish them together
   glab mr note draft create 123 --file src/cache.ts --line 42 -m "Please extract this branch"
   glab mr note draft list 123 --output json
   glab mr note draft publish 123 --reviewer-state requested_changes --yes
   
   # Attach evidence to a new or existing note
   glab mr note create 123 -m "Rendered result" --attach ./result.png
   glab mr note update 123 456789 --attach ./updated.png
   
   # List discussion threads and expose note/discussion IDs (experimental)
   glab mr note list 123
   glab mr note list 123 --state unresolved --type diff
   glab mr note list 123 --output json
   
   # Resolve or reopen a discussion by note/discussion ID (experimental)
   glab mr note resolve 123 3107030349
   glab mr note reopen 123 3107030349
   

   glab mr note update では、ノート ID は常に最後の位置引数です。ヘルプの表示では必須引数がオプション引数より先に表示されますが、コマンドは最後の引数を <note-id> として解析します。MR を指定する場合は、glab mr note update <mr> <note-id> を使用してください。

4. 承認する：

   glab mr approve 123
   

自動レビューワークフロー：

繰り返し行うレビュー作業には、このスキルに含まれる scripts/ 配下の自動化スクリプトを使用してください （以下のパスはスキル自体のディレクトリからの相対パスです）。

scripts/mr-review-workflow.sh 123
scripts/mr-review-workflow.sh 123 "pnpm test"

これにより、チェックアウト → テストの実行 → 結果の投稿 → テストに合格した場合の承認が自動的に行われます。

マージ戦略

パイプラインの成功後に自動マージする：

glab mr merge 123 --when-pipeline-succeeds --remove-source-branch

マージの出力には、結果のマージリクエストの状態が正確に報告されます。glab mr merge --auto-merge が成功しても、必ず Merged! と表示されるとは限りません。MR が自動マージの待機状態になっただけの場合、自動化では承認済みの状態を、すでにマージ済みではなく保留中として扱う必要があります。

コミットをスカッシュする：

glab mr merge 123 --squash

マージ前にリベースする：

glab mr rebase 123
glab mr merge 123

トラブルシューティング

マージコンフリクト：

• MR をチェックアウトする：glab mr checkout 123
• エディターで手動でコンフリクトを解決する
• 解決内容をコミットする：git add . && git commit
• プッシュする：git push

MR を承認できない：

• 自分が作成者かどうかを確認する（ほとんどの設定では自分自身の MR を承認できません）
• 権限を確認する：glab mr approvers 123
• MR がドラフト状態でないことを確認する

パイプラインが必須なのに実行されない：

• ブランチに .gitlab-ci.yml があることを確認する
• プロジェクトで CI/CD が有効になっていることを確認する
• 手動でトリガーする：glab ci run

「MR already exists」エラー：

• ブランチから既存の MR を一覧表示する：glab mr list --source-branch <branch>
• 不要になった古い MR をクローズする：glab mr close <id>
• または既存の MR を更新する：glab mr update <id> --title "New title"

関連スキル

イシューの操作：

• イシューの作成と管理については glab-issue を参照してください
• glab mr for <issue-id> を使用すると、イシューにリンクされた MR を作成できます
• スクリプト：scripts/create-mr-from-issue.sh はブランチと MR の作成を自動化します

CI/CD との統合：

• マージ前のパイプラインの状態については glab-ci を参照してください
• 最初から自動マージをリクエストするには glab mr create --auto-merge を使用します。既存の MR では glab mr merge --when-pipeline-succeeds を使用します

自動化：

• スクリプト：自動レビューとテストのワークフローには scripts/mr-review-workflow.sh を使用します

MR のディスカッションの一覧表示と対象指定

glab mr note list のテキスト出力には、各ノートの ID と、システム以外のすべてのディスカッションについて 8 文字のディスカッション ID のプレフィックスが含まれ、相対タイムスタンプと絶対タイムスタンプの両方も表示されます。省略記号より前の文字をそのまま --reply に渡してください。ワークフローで完全なディスカッション ID が必要な場合は、JSON を使用してください。作成者や本文のテキストをスクレイピングするのではなく、確認済みの識別子を resolve、reopen、または --reply とともに使用してください。

# Filter the text view
glab mr note list 123 --type diff --state unresolved
glab mr note list 123 --file src/app.ts

# Prefer JSON when an automation needs stable IDs
glab mr note list 123 --output json \
  --jq '.[] | {discussion_id: .id, note_ids: [.notes[].id]}'

# Extract full discussion IDs
glab mr note list 123 -F json --jq '.[].id'

# Act on the verified identifier
glab mr note resolve 123 <discussion-or-note-id>
glab mr note reopen 123 <discussion-or-note-id>

上流の生成されたヘルプでは、外部の jq パイプを使って同じ情報を抽出する方法が示されています。このスキルセットでは、フィルタリングを glab 内で完結させ、別個のシェルプロセスを避けるため、サポートされている組み込みの --jq フラグを推奨します。

--type には all、general、diff、system を指定できます。--state には all、resolved、unresolved を指定できます。--file を指定すると、結果を 1 つのパス上の差分ノートに限定できます。これらのサブコマンドは引き続き実験的なため、異なるバージョンの glab をまたいでスクリプトを実行する場合は、最新のヘルプを確認してください。

テキスト出力では、デフォルトの --type all に通常のディスカッションだけでなく、システムノートも含まれます。システムのアクティビティのみが必要な場合は --type system を使用するか、自動化で割り当てやステータスのイベントをユーザーからのフィードバックとして解析しないよう、より限定的なノートの種類を選択してください。

ネイティブの MR ノートフロー（glab mr note create）

新しい MR ディスカッションの投稿には、glab mr note create コマンドを推奨します。

次の場合はネイティブの glab mr note create を使用

# New top-level discussion/comment
glab mr note create 123 -m "Please add a regression test"

# Non-resolvable note for automation/status output
glab mr note create 123 -m "Build status: green" --resolvable=false

# Reply to an existing discussion thread
glab mr note create 123 --reply abc12345 -m "Fixed in the latest push"

# File-level diff comment
glab mr note create 123 --file src/app.ts -m "General concern on this file"

# Line comment on the new side of the diff
glab mr note create 123 --file src/app.ts --line 84 -m "This branch can return null"

# Range comment on the new side
glab mr note create 123 --file src/app.ts --line 84:96 -m "Consider extracting this block"

# Comment on a removed line from the old side
glab mr note create 123 --file src/app.ts --old-line 37 -m "Why was this guard removed?"

上流のヘルプ／ドキュメントで覚えておくべきフラグのルール：

• --reply は、新しいディスカッションを開始するのではなく、既存のディスカッションスレッドを対象にします。
• --reply には、完全なディスカッション ID、または 8 文字以上の一意のプレフィックスを指定できます。
• デフォルトでは、新しいトップレベルのノートは解決可能なディスカッションスレッドとして作成されます。すべてのスレッドの解決を必須とするプロジェクトで妨げにならないボット／ステータスコメントには、--resolvable=false を使用してください。
• --line と --old-line には --file が必要で、同時には使用できません。
• --file、--reply、--unique は相互に排他的です。
• --resolvable=false は --reply、--file、--line、--old-line と組み合わせることはできません。
• 保留中のレビューコメントには mr note create --draft ではなく、glab mr note draft create を使用してください。ドラフトの作成では、差分の対象指定、返信、添付ファイルがサポートされていますが、--unique、--resolvable、--internal はサポートされていません。
• --internal を指定すると、プロジェクトメンバーのみに表示されるノートが作成されます。差分の対象指定（--file、--line、--old-line）とは組み合わせられず、新しいトップレベルの内部ノートで --resolvable=true を明示的に要求することもできません。
• --reply --internal を指定した場合、glab は公開スレッドへの投稿を拒否します。内部スレッドへの返信は、--internal を省略しても内部のままです。
• --attach は繰り返し指定でき、ノート本文全体を指定することもできます。アップロードごとに新しい URL が生成されるため、--unique とは組み合わせられません。
• mr note update では、添付ファイルのみを指定すると現在のノート本文に追記されます。--message と添付ファイルを組み合わせると、本文が置き換えられた後に新しい参照先が追記されます。
• ファイル単位の差分コメントを投稿する場合は、--line と --old-line の両方を省略してください。

レビュー待ちコメント

複数のレビュー指摘を公開前に一時保存しておきたい場合は、レビュー待ちコメントを使用します。

glab mr note draft create 123 --file src/app.ts --line 84 \
  -m "This branch can return null"
glab mr note draft create 123 --reply abc12345 \
  -m "I reproduced this locally"

# Inspect only your own pending comments before publishing
glab mr note draft list 123 --output json

# Review state is not an approval; use glab mr approve separately when appropriate.
glab mr note draft publish 123 \
  --message "A few blockers, see the comments." \
  --reviewer-state requested_changes \
  --yes

publish は、自分のレビュー待ちコメントのみを公開します。--reviewer-state には requested_changes または reviewed を指定できますが、どちらも正式な承認を記録するものではありません。マージリクエストの作成者が --reviewer-state を指定しても、レビュー担当者にも指定されていない限り GitLab は無視し、glab はその条件について警告します。--internal は任意の要約コメントにのみ適用され、--message が必要です。非対話型の実行には --yes が必要で、レビュー待ちコメントがない場合は公開に失敗します。添付ファイルは、コメント自体がレビュー待ちの間でも直ちにアップロードされます。

draft create は、レビュー待ちコメントの数値 ID を出力します。draft update または draft delete で使うため、保存しておいてください。これは公開済みコメント ID やディスカッション ID ではありません。MR を指定した場合、パーサーは下書き ID を最後に指定することを想定していますが、レンダラーは必須引数を先に表示します。

# Inspect the selected draft before changing it
glab mr note draft list 123 --output json
glab mr note draft update 123 456 -m "Revised finding"
# Delete only after explicit approval; this affects your pending review
glab mr note draft delete 123 456 --yes

draft update で変更できるのは本文のみで、差分上の位置は変更できません。位置を保持できないため、画像位置を指定した下書きは CLI から更新できません。添付ファイルのみを更新すると既存の本文に追記されますが、明示的にメッセージを指定すると、添付ファイルへの参照が追加される前に本文が置き換えられます。draft delete は --yes を指定しない限り確認を求めます。下書きコマンドグループが操作するのは自分のレビュー待ちコメントのみです。他のレビュー担当者の下書きは一覧表示、編集、削除、公開のいずれもできません。削除された mr note publish コマンドは使用しないでください。--help は親コマンドのヘルプにフォールバックするため、コマンドがまだ存在する証拠にはなりません。

次のような場合はヘルパー／スクリプトの方法を使います

自動化でより確実なアンカーを設定する必要がある場合、特に次のような場合は、同梱のインラインコメントヘルパー、または JSON ボディを使った glab api の方法を使用します。

• GitLab がルート MR コメントではなく、実際のインラインディスカッションを作成したことを確認する必要がある場合
• 多数のコメントを一括投稿する場合
• 扱いにくい差分（新規ファイル、名前変更されたファイル、複雑なパス、行コードへのフォールバックが発生するケース）を対象にする場合

glab mr note create は、ほとんどの対話型の返信や差分コメントのワークフローに十分対応できます。堅牢な自動レビューのパイプラインでは、引き続きヘルパーが役立ちます。

MR の差分にインラインコメントを投稿する

glab api --field の問題

glab v1.118.0 では、JSON リクエストボディを作成する必要がある場合、glab api --field position[new_line]=N は即座に失敗します。

a field name containing a bracket is not supported in a JSON request body

インライン MR ディスカッションのボディを作成するために、角括弧付きのフィールド名は使用しないでください。以前のフォーム形式の位置ペイロードも、次のケースでは不安定でした。

• 完全な新規ファイル（差分で new_file: true となる場合）
• 複雑なパスやエンコードされたパスを持つファイル
• フォームエンコードで保持されないネストされた位置フィールド

インラインディスカッションを作成する場合は、JSON ボディを指定した --input - を使用してください。返されたコメントの position フィールドを必ず確認し、自動化でルート MR コメントやアンカー設定の失敗を検出できるようにしてください。

解決策：常に JSON ボディを使用する

リテラルの JSON リクエストボディを使って、glab api 経由でインラインコメントを投稿します。認証は常に glab に任せ、保存済みのトークン値を読み取ったり、コピーしたり、ログに記録したり、出力したりしないでください。

set -euo pipefail

HOST="gitlab.com"
PROJECT_PATH="mygroup/myproject"
MR_IID="42"
FILE_PATH="src/utils/helpers.ts"
LINE="16"
BODY="Your comment here"

# Confirm the exact GitLab host and visible account before creating a discussion.
glab auth status --hostname "$HOST"
glab api --hostname "$HOST" /user | jq '{username: .username, name: .name}'

PROJECT_ID="$(python3 -c 'import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1], safe=""))' "$PROJECT_PATH")"

# Always fetch fresh SHAs from the current MR version; never use cached values.
VERSION_JSON="$(glab api --hostname "$HOST" "/projects/$PROJECT_ID/merge_requests/$MR_IID/versions" | jq '.[0]')"

python3 - "$VERSION_JSON" "$FILE_PATH" "$LINE" "$BODY" <<'PY' |
import json
import sys

version = json.loads(sys.argv[1])
file_path = sys.argv[2]
line = int(sys.argv[3])
body = sys.argv[4]

json.dump({
    "body": body,
    "position": {
        "base_sha": version["base_commit_sha"],
        "start_sha": version["start_commit_sha"],
        "head_sha": version["head_commit_sha"],
        "position_type": "text",
        "new_path": file_path,
        "new_line": line,
        "old_path": file_path,
        "old_line": None
    }
}, sys.stdout)
PY
glab api --hostname "$HOST" --method POST --header "Content-Type: application/json" --input - \
  "/projects/$PROJECT_ID/merge_requests/$MR_IID/discussions" |
  jq '{discussion_id: .id, inline: ((.notes[0].position // null) != null)}'

返された inline の値は true でなければなりません。false の場合は、結果をルート MR ディスカッションとして扱い、インラインアンカーの設定に成功したと主張しないでください。

正しい行番号を見つける

行番号は、差分内の追加された行（+ プレフィックス）を指す必要があります。コンテキスト行や削除された行を指定すると、位置が拒否されます。

import re

def get_new_line_number(diff_text, keyword):
    """Find the new_file line number of the first added line containing keyword."""
    new_line = 0
    for line in diff_text.split("\n"):
        hunk = re.match(r"@@ -\d+(?:,\d+)? \+(\d+)(?:,\d+)? @@", line)
        if hunk:
            new_line = int(hunk.group(1)) - 1
            continue
        if line.startswith("-") or line.startswith("\\"):
            continue
        new_line += 1
        if line.startswith("+") and keyword in line:
            return new_line
    return None

# Usage
diffs = json.loads(...)  # from /merge_requests/{iid}/diffs
for d in diffs:
    if d["new_path"] == "src/utils/helpers.ts":
        line = get_new_line_number(d["diff"], "safeParse")
        print("line:", line)

再利用可能なスクリプト

スクリプト化された MR レビューや自動化された MR レビューには、このスキルに同梱されている scripts/ のヘルパーを使用してください （以下のパスは、このスキルのディレクトリからの相対パスです）。

# Single comment
python3 scripts/post-inline-comment.py \
  --project "mygroup/myproject" \
  --mr 42 \
  --file "src/utils/helpers.ts" \
  --line 16 \
  --body "This returns the wrapper object — use .data instead."

# Batch from JSON file
python3 scripts/post-inline-comment.py \
  --project "mygroup/myproject" \
  --mr 42 \
  --batch comments.json

バッチファイルの形式：

[
  { "file": "src/utils/helpers.ts", "line": 16, "body": "Comment 1" },
  { "file": "src/routes/+page.svelte", "line": 58, "body": "Comment 2" }
]

このスクリプトは認証を glab に任せ、glab api を通じて最新の SHA と差分を取得し、次の 2 段階のアンカー付け戦略を使用します。

1. まず、通常の JSON position.new_line インラインペイロードを試します。
2. GitLab が line_code の検証エラーで拒否した場合は、差分アンカーを計算し、JSON の position.line_range.start.line_code ／ position.line_range.end.line_code を使って再試行します。

次のようなエラーが発生した場合は、この再試行方法での復旧が推奨されます。

• 400 Bad request - Note {:line_code=>["can't be blank", "must be a valid line code"]}

再試行も失敗した場合に限り、より広範なレビューのワークフローではルート MR ノートに切り替えてください。その際は、インラインアンカー付けに失敗したことを明記し、指摘内容とレビュアーの本人性を正確に維持してください。

---

解決状況によるディスカッションスレッドの絞り込み

# Show only unresolved discussion threads on an MR
glab mr view 123 --unresolved

# Show only resolved threads
glab mr view 123 --resolved

マージ前に、まだ対応が必要なレビュースレッドをすばやく確認するのに便利です。

glab mr view の通常のテキスト出力には、ソースブランチとターゲットブランチが表示されるようになりました。特にフォークのマージリクエストでは、レビュー、リベース、マージの前に、表示された source → target の向きを確認してください。自動化で表示行を解析する代わりに安定したブランチフィールドが必要な場合は、--output json を使用してください。

glab mr list の絞り込みフラグ

glab mr list は、次の絞り込みフラグと並べ替えフラグに対応しています。

# Filter by author
glab mr list --author <username>

# Filter by source or target branch
glab mr list --source-branch feature/my-branch
glab mr list --target-branch main

# Filter by draft status
glab mr list --draft
glab mr list --not-draft

# Filter by label or exclude label
glab mr list --label bugfix
glab mr list --not-label wip

# Order and sort
glab mr list --order updated_at --sort desc
glab mr list --order merged_at --sort asc

# Date range filtering
glab mr list --created-after 2026-01-01
glab mr list --created-before 2026-03-01

# Search in title/description
glab mr list --search "login fix"

# Full flag reference (all available flags)
glab mr list \
  --assignee @me \
  --author vince \
  --reviewer @me \
  --label bugfix \
  --not-label wip \
  --source-branch feature/x \
  --target-branch main \
  --milestone "v2.0" \
  --draft \
  --state opened \
  --order updated_at \
  --sort desc \
  --search "auth" \
  --created-after 2026-01-01

構造化出力

glab mr approvers は構造化出力に --output json ／ -F json をサポートしており、エージェントによる自動化に便利です。

# View MR approvers with JSON output
glab mr approvers 123 --output json
glab mr approvers 123 -F json

コマンドリファレンス

すべてのコマンドのドキュメントとフラグについては、references/commands.md を参照してください。

使用可能なコマンド：

• approve - マージリクエストを承認します
• checkout - MR をローカルにチェックアウトします
• close - マージリクエストをクローズします
• create - 新しい MR を作成します
• delete - マージリクエストを削除します
• diff - MR の変更を表示します
• for - イシューの MR を作成します
• list - マージリクエストを一覧表示します
• merge - MR をマージ／承認します
• note - MR のディスカッションコマンドです。新しいコメントには glab mr note create を使用し、list、resolve、reopen も使用できます
• rebase - ソースブランチをリベースします
• reopen - マージリクエストを再オープンします
• revoke - 承認を取り消します
• subscribe ／ unsubscribe - 通知を管理します
• todo - ToDo 項目を追加します
• update - MR のメタデータを更新します
• view - MR の詳細を表示します