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

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

この状態は何をすると起きるか

典型的なパターンは、git initのあとgit fetch <url>でリモートの内容を取得し、git checkout FETCH_HEADで直接チェックアウトする操作です。この手順ではローカルの.gitにFETCH_HEADというコミットへの参照だけが残り、ブランチもタグも1つも作られません。結果としてdetached HEADではあるのに、リポジトリ全体を見渡してもブランチが0本という状態になります。

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.

普段のクローンでタグやコミットハッシュを指定してチェックアウトしたときに起きる「detached HEAD」とは事情が違う点に注意します。通常のクローンなら他のブランチが既にリポジトリ内に存在します。たとえ今チェックアウトしているのがdetached HEADでも、ultrareviewはリポジトリ内の他のブランチを頼りにバンドルを作れます。このエラーが出るのは、リポジトリ全体を見渡してもブランチが本当に1本も無い場合だけです。

gitバンドルがブランチを前提にする理由

git bundleはリポジトリの内容を1つのファイルにまとめて持ち運ぶための標準的な仕組みです。その作り方は「どの参照(ブランチやタグ)から辿れるコミットを含めるか」を指定する形になっています。参照そのものが1つも無ければ、バンドルに何を含めればいいのかをgit自身が決められません。ultrareviewがブランチレビューでリポジトリをアップロードするときにこの仕組みを使っている以上、参照が無いチェックアウトはバンドル化の入り口でつまずくことになります。エラーメッセージが「バンドルできない」と明言しているのは、この技術的な制約をそのまま反映したものです。

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

対処はメッセージが示す通りです。現在のコミットにブランチを1本作ってから、あらためてレビューを実行します。

git checkout -b review-branch

ブランチ名は何でも構いません。レビュー専用の一時的な名前を付けておけば、用が済んだ後にgit branch -dで消してもリポジトリの他の状態には影響しません。ブランチを作成した後、/code-review ultraを再実行します。

/code-review ultra

v2.1.221より前は、この状態のチェックアウトに対してClaude Codeがリポジトリ内の追跡対象ファイルすべてをレビューしようと試みていました。結果としてアップロード自体が失敗するという、不親切な失敗の仕方をしていました。v2.1.221以降は、アップロードを試みる前に「ブランチが無い」と判定してこのメッセージを出すようになり、git checkout -bという具体的な対処が最初から示されるようになっています。

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

git checkout -bでブランチを作りたくない事情がある場合、対象の変更が既にGitHub上のプルリクエストになっているなら、PR番号を指定してレビューする方法があります。

/code-review ultra 1234

ブランチレビューはローカルの作業ツリーをバンドルしてアップロードします。一方PRモードは、リモートサンドボックスがGitHub側から直接プルリクエストをクローンする経路で、ローカルのチェックアウトを一切アップロードしません。ブランチが1本も無い状態そのものがPRモードでは問題にならないため、ローカルの状態を変えたくないCIジョブやスクリプトからのレビューでは、可能ならPR番号を指定する方が確実です。ただしPRモードが使えるのはgithub.comまたは接続済みのGitHub Enterprise Serverインスタンス上のリポジトリに限られます。

submoduleでも起きやすい構成がある

git submoduleの初期化は、既定では特定のコミットへdetached HEADでチェックアウトするだけで、ブランチを作りません。サブモジュール側のディレクトリで単独に/code-review ultraを実行しようとすると、親リポジトリとは無関係に同じエラーに行き当たります。対処は同じで、サブモジュール側のディレクトリでgit checkout -b <name>を実行してからレビューします。

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

この状態は手作業のgit操作より、スクリプトや自動化パイプラインが「特定のコミットだけを取得してすぐ作業を始める」ような最小限のチェックアウトを組んだときに起きやすい傾向があります。ブランチの追跡設定を省略し、fetchとcheckoutだけで完結させる構成は、通常の開発では意識しない「ブランチが0本のリポジトリ」を作り出してしまいます。

worktreeを使っている場合は原因の切り分けが必要

git worktree addでブランチ名を省略し、代わりにコミットハッシュを渡すと、その作業ツリー単体はdetached HEADになります。ただしgit worktreeで作った作業ツリーは、メインの作業ツリーと同じリポジトリのブランチ一覧を共有します。worktree内のチェックアウト自体がdetached HEADであっても、リポジトリ全体としては他のworktreeやメインの作業ツリーが使っているブランチが存在します。そのため、このエラーの条件である「ブランチが本当に1本も無い」状態には通常なりません。worktree運用中にこのエラーが出た場合は、worktree自体の設定よりも、リポジトリ全体をどう取得したか(fetchやcloneの方法)を先に疑う方が的確です。worktreeごとの隔離設計や落とし穴はClaude Code Worktree実践ガイド — 並列セッションの隔離と落とし穴にまとめています。

ローカルの/code-reviewには影響しない

このエラーはultrareview固有の制約です。クラウドへのアップロードを伴わないローカルの/code-reviewは、現在のワーキングツリーの内容を直接読んで差分を評価するため、ブランチが0本の状態でも普通に動作します。急ぎで何かしらのレビューが欲しいだけなら、ブランチを作る手間をかけずにローカルレビューへ切り替えるのも実用的な選択です。クラウドとローカルそれぞれの実行経路の違いはClaude Codeコードレビュー — 4つの実行経路の使い分けで扱っています。

よくある質問

タグやコミットハッシュをチェックアウトしただけでも出ますか

出ません。通常のクローンでタグやコミットハッシュを指定してdetached HEADになった場合、リポジトリ内には他のブランチが存在しているため、ultrareviewはそれらを使ってバンドルできます。このエラーが出るのは、リポジトリ全体でブランチが本当に1本も無い、より特殊な状態のときだけです。

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

問題ありません。レビューのためだけに作ったブランチは、用が済んだらgit branch -d <name>で削除できます。ultrareviewのレビュー自体はクラウド側で完結しており、ローカルのブランチが後で消えても影響しません。

git checkout -bした直後にもう一度エラーが出ることはありますか

通常はありません。ブランチを作成した時点でリポジトリにブランチが1本存在する状態になるため、同じ原因での拒否は起きなくなります。それでも別のエラーが出る場合は、ベースブランチとの共有履歴が無い可能性があります。「Could not find merge-base」の対処が扱う原因に当てはまることがあります。

CI環境でこのエラーを避けるにはどう設定すればいいですか

チェックアウトのステップで、対象のコミットを取得するだけでなくブランチとして明示的にチェックアウトするよう設定を見直します。取得したコミットに対してgit checkout -b <name>を1行加えるだけで、ブランチが0本の状態は回避できます。

submoduleのディレクトリの中でこのエラーが出たらどうしますか

親リポジトリではなく、そのサブモジュール自体のディレクトリに移動してgit checkout -b <name>を実行します。サブモジュールは既定でdetached HEADのままブランチを作らないため、親リポジトリ側にブランチがあっても解決しません。

v2.1.221より前のバージョンではどう表示されていましたか

エラーメッセージは表示されず、Claude Codeがリポジトリ内の追跡対象ファイルすべてをレビューしようと試みたうえで、アップロードそのものが失敗していました。原因が分かりにくい失敗の仕方だったため、v2.1.221で「バンドルできない」と事前に判定してこの明示的なメッセージを返す形に変わっています。

エラーメッセージの<name>には何を入れればいいですか

任意のブランチ名です。既存のブランチ名と重複しなければ内容に決まりはなく、レビュー用と分かる一時的な名前(review-branchやwipなど)で十分です。

ブランチを作った後、そのブランチをリモートにpushする必要はありますか

ブランチレビューはローカルの作業ツリーをバンドルしてアップロードする経路なので、pushは不要です。ローカルにブランチが1本存在してさえいれば、Claude Codeはそのローカルの状態をそのままバンドル化してレビューを開始できます。

ブランチを作らずに済ませる方法は他にありませんか

ローカルでの対処としてはgit checkout -bが最短です。GitHub上にすでにプルリクエストがあるなら、前述のPRモードでローカルのブランチ状態を変えずにレビューできます。どちらも使えない状況(PRも無く、ブランチも作りたくない)では、クラウドへのアップロードを伴わないローカルの/code-reviewに切り替えるのが現実的な代替です。