「Could not find merge-base」の対処 — Claude Code
Claude Codeのultrareviewが「Could not find merge-base with the base branch」で拒否したときの3パターンの見分け方と、fetch・ベースブランチ指定による対処を確認します。
/code-review ultraまたはclaude ultrareviewが拒否することがあります。表示されるのは「Could not find merge-base with the base branch」というメッセージです。ultrareviewはブランチとベースブランチが共有する分岐元コミット(merge-base)を起点に差分を計算する設計です。git merge-baseがその共有コミットを1つも見つけられないと、クラウドセッションを起動する前にレビューを拒否します。
メッセージ本体とヒント行は別物
エラーは2行構成です。1行目は共通の定型文、2行目のヒントは何が原因でmerge-baseが見つからなかったかで内容が変わります。
Could not find merge-base with main. Pass the base branch explicitly (e.g. `/code-review ultra develop`) or make sure you're in a git repo with a main branch.ヒントの出し分けは3パターンです。
| 状況 | ヒントの内容 |
|---|---|
| ベースブランチを何も指定しなかった | ヒントの内容リポジトリの既定ブランチと比較した結果なので、比較対象を明示するよう提案 |
| 指定したベースブランチがローカルクローンに既にあった | ヒントの内容Make sure <branch> exists locally or on origin(git fetch origin <branch>を試すよう案内) |
| 指定したベースブランチがローカルクローンになかった | ヒントの内容Claude Codeがoriginから取得済みだがHEADと共通の履歴を持たない、または浅いクローンかどうか判断できない場合はgit fetch --unshallow originを提案 |
3つ目のパターンのうち「共通の履歴を持たない」ヒントは、指定したブランチが実は無関係なプロジェクトの別ブランチだった、あるいは本当に別のベースを指定すべきだったケースで出ます。「浅いクローンかどうか判断できない」ヒントは、次の節で扱うshallow clone特有の状況です。
merge-baseが見つからないと必ず拒否されるわけではない
git merge-baseが見つからない状況でも常に拒否されるわけではありません。Claude Codeがクローンを完全なものと確認でき、かつブランチが最低1つ存在する場合は、リポジトリ内の追跡対象ファイルすべてをレビューする形にフォールバックします。このフォールバックは完全なクローンを前提とし、通常のブランチレビューと同じファイル数・行数の上限が適用されます。拒否になるのは、次のいずれかに当てはまるときだけです。
- ベースブランチがそもそも見つからない
- クローンが完全かどうかをClaude Codeが判断できない
- リポジトリ全体の差分計算自体ができない特殊なケース(SHA-256オブジェクト形式など)
ブランチが1本も無いdetached HEADのチェックアウトは、この判断以前の別のエラーになります。detached HEAD特有の挙動は「Your checkout has no branches」の対処で扱っています。
ベースブランチを明示して再実行する
最初に試す対処は、比較対象のベースブランチを明示的に渡すことです。
/code-review ultra develop指定したブランチがローカルクローンに存在しなくても、Claude Codeがoriginから取得したうえで比較します。存在しないブランチ名を渡すと、次はヒントが「fetch済みだが共通履歴が無い」に変わり、本当に正しいブランチ名かどうかを見直す手がかりになります。
shallow cloneならfetchで履歴を補う
CIランナーの多くはgit clone --depth=1のようなshallow cloneを使います。この状態ではorigin/mainのようなリモート追跡ブランチ自体は存在していても、共有コミットを遡って探すための履歴が足りず、merge-baseの計算が失敗します。ヒントにgit fetch --unshallow originが出た場合は、そのまま実行して履歴を取得してから再実行します。
git fetch --unshallow originv2.1.221より前は、fetch済みのベースブランチに対して常にこのヒントを出していました。そのためクローンが既に完全な状態でも同じ提案が表示されていました。実行するとfatal: --unshallow on a complete repository does not make senseで失敗する不具合がありました。v2.1.221以降はクローンが完全かどうかを判定したうえでヒントを出し分けるようになり、この空振りは起きなくなっています。
オーファンブランチも共有履歴が無いため同じエラーになる
意図的に共有履歴を持たないブランチを作る操作もあります。git checkout --orphanは、既存のどのブランチともコミット履歴を共有しない、まっさらなブランチを作るコマンドです。ドキュメント専用のブランチやgh-pagesのような公開用ブランチを本体のコード履歴と切り離して管理する目的でよく使われますが、この設計そのものがultrareviewの前提と噛み合いません。オーファンブランチと通常のブランチの間には共有コミットが存在しないため、git merge-baseは必ず失敗します。
このケースでは「ヒントに従って対処すれば直る」問題ではなく、そもそも設計上merge-baseが存在しないブランチだと理解しておく必要があります。オーファンブランチの内容をレビューしたい場合は、ベースブランチの指定を諦め、対象のファイルパスを個別に指定してローカルの/code-reviewにかける方が現実的です。
似た場面で出る別のエラーと混同しない
ultrareviewは起動前にいくつかの差分チェックを順に行っており、「Could not find merge-base」以外にも似た場面で出るメッセージがあります。ベースとの差分そのものが空の場合は、merge-baseの計算自体は成功したうえで「差分が無い」という別の案内になり、変更をステージ・コミットするか別のベースを指定するよう促されます。この2つは見た目が近いものの、原因が「比較の起点が見つからない」のか「起点は見つかったが差分が無い」のかで根本的に違うため、表示されたメッセージの文言を読み違えないようにします。
稀に起きるリポジトリ形式そのものの制約
ドキュメントはもう1つ、極めて稀なケースとしてSHA-256オブジェクト形式のリポジトリを挙げています。この形式ではリポジトリ全体の差分計算そのものが通常の方式と異なり、フォールバックとしての全ファイルレビューが成立しません。該当するリポジトリは限られており、通常のSHA-1形式のgitリポジトリを使っている限りはまず遭遇しない制約です。
ベースブランチの履歴を書き換えた直後にも起きうる
ベースブランチ側で強制的な履歴の書き換え(force-pushを伴うリベースなど)が行われた直後にも起きます。ローカルに残っている古いベースブランチの参照と、実際に取得し直したベースブランチとの間で共有コミットの位置がずれ、想定していたところにmerge-baseが見つからないことがあります。この場合はローカルの参照が古いだけなので、git fetch origin <branch>で最新の状態を取得し直してから再実行すると解決します。日常的な運用でリベースを多用するチームほど、この種のずれに遭遇しやすくなります。
リポジトリにoriginが無い場合
ローカルでgit initしただけでリモートを追加していないリポジトリでは、originから取得するという前提そのものが成立しません。この場合はまずgit remote add origin <url>でリモートを登録し、git fetchしてから再実行します。複数のクローンやCI環境でfetch設定がそれぞれ分かれている場合も、どこか1つのクローンでベースブランチをfetchし忘れていると同じエラーになりがちです。並列セッションでのworktree運用についてはClaude Code Worktree実践ガイド — 並列セッションの隔離と落とし穴で扱っています。
よくある質問
ヒントに従ってfetch --unshallowしても直りませんか
直らない場合、そもそも比較しようとしているベースブランチが間違っている可能性があります。ヒントが「共通の履歴を持たない」に変わっていないか確認し、変わっていれば正しいベースブランチ名を明示的に渡します。
mainブランチが存在しないリポジトリではどうなりますか
既定ブランチとして参照する対象が無いため、比較先を持てず同じエラーになります。/code-review ultra <branch>でリポジトリに実在するブランチを明示します。
フォールバックで全ファイルレビューになったかはどう分かりますか
拒否メッセージが出ず通常通りレビューが進んだ場合、フォールバックが効いた可能性があります。差分ベースのレビューより対象範囲が広くなるため、レビューの所要時間や指摘件数が普段より多いと感じたら、ベースブランチを明示して差分ベースに戻すことを検討します。
PRレビューでもこのエラーは出ますか
PRモードはリモートのサンドボックスがGitHub側から直接クローンして比較する別経路で、ローカルの履歴の深さは関係しません。ブランチレビューと同列に「同じエラーが出る」とは言えないため、PRレビューで同種の問題に当たった場合はブランチレビュー向けのこの記事の手順をそのまま適用せず、まずどちらのモードで実行しているかを確認してください。
オーファンブランチをどうしてもultrareviewでレビューしたい場合はどうしますか
比較対象となる共有コミットが存在しない設計のため、ブランチ比較の形でのレビューはできません。内容を検証したいなら、ベースブランチとの差分ではなくファイルパスを直接指定できるローカルの/code-reviewを使う方法に切り替えます。オーファンブランチの用途自体が「本体のコード履歴と意図的に切り離す」ことなので、この制約は設計上避けられないものと理解しておくのが実用的です。
git fetch origin <branch>とgit fetch --unshallow originはどちらを先に試すべきですか
ヒントの文言をそのまま手がかりにします。「exists locally or on origin」という文言ならgit fetch origin <branch>を試します。「浅いクローンかどうか判断できない」という趣旨の文言ならgit fetch --unshallow originです。どちらのヒントが出ているかで、足りていないのがブランチの取得なのか、コミット履歴の深さなのかが変わります。
CI環境ではどちらの原因が多いですか
CIランナーの多くはビルド時間短縮のためshallow cloneを既定にしており、履歴の深さ不足で失敗するケースが目立ちます。ワークフロー側でチェックアウトの深さ(depth)を制限している設定がないか確認します。必要な範囲だけでもgit fetch --unshallow originか、深さを広げたfetchに切り替えます。
毎回--unshallowすると時間がかかりすぎませんか
リポジトリが大きいほど、履歴全体を取得する--unshallowはネットワーク転送量も時間もかかります。CIのたびに毎回実行するくらいなら、そもそもultrareviewを走らせるジョブだけ十分な深さでチェックアウトするよう、ワークフロー側の設定を恒久的に見直す方が長期的には効率的です。単発の手元での作業であれば、--unshallowより必要な範囲だけ深さを広げるgit fetch --depth=<N> origin <branch>のほうが速く済むこともあります。