「Your checkout has no branches」の対処 — Claude Code

/code-review ultraまたはclaude ultrareviewが「Your checkout has no branches」と表示して拒否することがあります。ultrareviewはリポジトリをgitバンドルとしてパッケージ化し、クラウドのサンドボックスへアップロードします。ブランチも他の参照(タグなど)も1つも無いチェックアウトはバンドルできないため、クラウドセッションが始まる前に止まります。

手元のチェックアウトが当てはまるかを確かめる

エラーが指しているのは「detached HEADであること」ではなく、「リポジトリ全体で参照が1つも無いこと」です。診断は2つのコマンドで済みます。

git branch -a
git for-each-ref

git initとgit fetch、git checkout FETCH_HEADで作ったチェックアウトでは、出力は次のようになります。

* (HEAD detached at FETCH_HEAD)

git for-each-refのほうは1行も出ません。ここでgit checkout -b review-branchを実行すると、git for-each-refがrefs/heads/review-branchを1行返すようになり、バンドルする参照が揃います。

041f8da91904f66b7ef07694d83da35afa18414b commit	refs/heads/review-branch

FETCH_HEADは.git/FETCH_HEADというファイルに記録された取得結果で、ブランチやタグのような参照ではありません。タグ名を指定してgit fetch <url> v1としても、ローカルにタグは作られず、同じくFETCH_HEADに記録されるだけです。エラー文は次のとおりです。

Your checkout has no branches (detached HEAD only), which cloud review can't bundle. Create one first — `git checkout -b <name>` — then rerun /code-review ultra.

gitバンドルが参照を前提にする理由

git bundleは、リポジトリの内容を1つのファイルにまとめて持ち運ぶための標準的な仕組みです。作るときは「どの参照から辿れるコミットを含めるか」を指定します。参照が1つも無ければ、何を含めればよいのかをgit自身が決められません。ultrareviewが手元のブランチをアップロードする経路でこの仕組みを使うため、参照の無いチェックアウトはバンドル化の入り口で止まります。

通常のクローンなら、タグやコミットハッシュを指定してdetached HEADになっても、リポジトリ内にはブランチやリモート追跡ブランチが残っています。この場合はバンドルできるので、エラーは出ません。

git checkout -bでブランチを作って再実行する

対処はメッセージが示すとおりです。現在のコミットにブランチを1本作ってから、レビューをやり直します。

git checkout -b review-branch

レビュー専用の一時的な名前にしておけば、用が済んだあとに消せます。チェックアウト中のブランチはgit branch -dで消せないため、別のブランチへ移るかgit checkout --detachで外してから削除します。そのうえで/code-review ultraを再実行します。

/code-review ultra

Claude Codeはv2.1.221(2026年8月4日)から、ブランチが無いチェックアウトをアップロードの前に拒否し、git checkout -bでブランチを作る対処を示します。

ブランチを作った直後に待っている確認

参照が1本できても、そのリポジトリにはベースにできるブランチがありません。ultrareviewは通常、現在のブランチと既定ブランチの差分をレビューします。git initとgit fetchで作ったチェックアウトのように、比較できるベースブランチが無いリポジトリでは、追跡しているファイルをすべて対象にするフォールバックに切り替わります。

このフォールバックには条件がいくつかあります。

• 浅い取得ではなく、フルクローンが必要です
• 変更ファイルと行数の上限が、通常のレビューと同じようにかかります
• 起動するのは、確認ダイアログで承認したときか、claude ultrareviewを自分で実行したときだけです

手元の作業をクラウドへ送る経路には、サイズの条件もあります。バンドルするリポジトリは100MB未満でなければならず、超えると現在のブランチだけのバンドル、さらに作業ツリー1枚分のスナップショットへと縮小されます。コミットしていない新規ファイルは含まれないので、レビューしてほしいファイルにはgit addが要ります。macOS、Linux、WSLでは、.envや*.pemのような名前の認証情報ファイルは、未コミットの変更がアップロードから外されます。

プルリクエストがあるならPRモードで回避できる

git checkout -bでブランチを作りたくなく、変更がすでにGitHub上のプルリクエストになっているなら、PR番号を指定する方法があります。

/code-review ultra 1234

ブランチレビューは、ローカルの作業ツリーをバンドルしてアップロードします。PRモードでは、クラウドのサンドボックスがホスト側から直接プルリクエストをクローンし、手元のマシンからは何もアップロードしません。ブランチが無い状態はPRモードでは問題にならないため、ローカルの状態を変えたくないスクリプトからのレビューでは、PR番号を渡す方が確実です。

PRモードが使えるのは、github.comのリポジトリか、Ownerが接続済みのGitHub Enterprise Serverのインスタンスにあるリポジトリです。claude ultrareview 1234のようにサブコマンドでもPR番号を渡せます。claude ultrareview --helpは、v2.1.289で次のオプションを表示します。

Usage: claude ultrareview [options] [target]
 
Options:
  -h, --help           Display help for command
  --json               Print the raw bugs.json payload instead of formatted findings
  --no-post            Do not post the findings to the PR (the default; ...)
  --post               Post the finished review's findings to the PR as you (PR
                       targets only; one plain comment, not a review)
  --timeout <minutes>  Maximum minutes to wait for the review to finish
                       (default: 45)

--postはv2.1.227以降で使え、github.comのプルリクエストにだけ効きます。ブランチ指定やGitHub Enterprise Serverでは、指摘がセッション内に表示されるだけです。

ほかの拒否と取り違えやすい点

ultrareviewは、アップロードの前に差分を検査してから実行します。参照が0本の拒否はその一つで、似た見た目の拒否が別にあります。メッセージに合わせて対処が変わります。

マージベースが無い場合は、全ファイルのレビューに切り替わる点が参照0本と違います。この経路は確認ダイアログの承認かclaude ultrareviewの直接実行が必要で、claude -pでは拒否されます。詳しくは「Could not find merge-base」の対処にあります。

サブモジュールとworktreeでの出方

git submodule updateで初期化したサブモジュールは、既定でdetached HEADになります。ただしgit clone --recurse-submodulesで取得したものなら、サブモジュール側にmainやorigin/mainといった参照が残ります。git branch -aがmainとremotes/origin/mainを返すので、このエラーの対象になりません。サブモジュールで出るのは、git initとgit fetchでサブモジュール相当のディレクトリを手作りしたような場合です。

git worktree addにコミットハッシュを渡すと、その作業ツリーはdetached HEADになります。ただしworktreeはメインの作業ツリーとリポジトリを共有するため、git branch -aには元のリポジトリのmainが+ mainとして並びます。worktree運用中にこのエラーが出たら、worktreeの設定より先に、リポジトリ自体をどう取得したかを疑う方が近道です。worktreeごとの隔離設計はClaude Code Worktree実践ガイド — 並列セッションの隔離と落とし穴で扱っています。

自動化されたチェックアウトで起きやすい

この状態は、手作業のgit操作より、スクリプトやパイプラインが特定のコミットだけを取得してすぐ作業を始める構成で起きやすくなります。git init、git fetch <url> <ref>、git checkout FETCH_HEADの3行で完結させると、ブランチは1本も作られません。ultrareviewを呼ぶ手前にgit checkout -b <name>を1行足すだけで、参照が0本の状態は避けられます。自動化から呼ぶなら、claude -p '/code-review ultra'ではなくclaude ultrareviewサブコマンドが向いています。claude -pの実行は、指摘が届く前に終了するためです。サブコマンドは進捗をstderrへ出し、--jsonを付ければstdoutでbugs.jsonを受け取れます。終了コードは、レビューの起動に失敗した場合、途中で止まった場合、クラウドセッションがエラーになった場合、タイムアウトした場合に1になります。ローカルのレビューとの違いはClaude Codeコードレビュー — 4つの実行経路の使い分けで扱っています。

よくある質問

作ったブランチは後で消しても問題ありませんか

問題ありません。レビュー専用に作ったブランチは、用が済んだら削除できます。チェックアウト中のブランチはgit branch -d <name>で消せないため、先に別のブランチへ移るかgit checkout --detachで外します。ただしこのブランチを消して参照が0本に戻ると、次のレビューで同じエラーになります。

ブランチをリモートにpushする必要はありますか

ありません。ブランチレビューは手元の作業ツリーをバンドルしてアップロードする経路なので、ローカルにブランチが1本あれば足ります。pushが要るのは、PRモードで使うプルリクエストを作るときです。

git checkout -bしたのに別のエラーが出ます

ブランチが1本できると、このエラーの原因は解消します。それでも拒否されるなら、前半の表のほかの条件です。ベースブランチと履歴を共有しない場合は、「Could not find merge-base」の対処の原因に当たることがあります。