divergent branchesの直し方｜git pullのエラー

fatal: Need to specify how to reconcile divergent branches. は、手元とリモートの両方に、相手が持っていないコミットがある状態で git pull したときのエラーです。 git は、2つの履歴をどうまとめるか（merge か rebase か）を決めるよう求めています。この時点では、何も変更されていません。

すぐに直すなら、次のどれかを実行します。

確認環境：git 2.43.0（確認日 2026年10月11日）。2つのクローンで、片方が push したあと、もう片方でも別のファイルをコミットして再現しました。

再現

$ git status
On branch main
Your branch and 'origin/main' have diverged,
and have 1 and 1 different commits each, respectively.

have 1 and 1 different commits：手元に1つ（自分の変更）、リモートに1つ（他の人の変更）、相手に無いコミットがあります。 これを「分岐した（diverged）」状態と呼びます。

$ git pull
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
...
fatal: Need to specify how to reconcile divergent branches.

手元にコミットが無い（分岐していない）ときは、このエラーにならず、そのまま pull できました。 自分がコミットしたあとの pull だけで出るので、「昨日まで動いていた pull が突然止まった」ように見えます。git の公式ドキュメントでは、まとめ方を指定しないときの既定は --ff-only の動き（分岐していると失敗する）とされています。

3つを実行した結果の履歴

同じ状態から、3つのやり方で git pull し、git log --graph --oneline --all で比べました。

--no-rebase（merge）

*   6052e10 Merge branch 'main' of .../origin
|\
| * 1820556 r1 他の人の変更
* | df505c8 l1 自分の変更
|/
* a926f26 c1 初期

マージのコミット（Merge branch 'main' ...）が1つ増え、2本の線が合流する形になりました。自分のコミット df505c8 の ID は変わりません。

--rebase

* 127ac1a l1 自分の変更          ← ID が df505c8 から 127ac1a に変わった
* 1820556 r1 他の人の変更
* a926f26 c1 初期

自分のコミットが、他の人の変更の後ろに付け直され、一直線の履歴になりました。マージのコミットは増えません。ただし、自分のコミットの ID が変わりました（作り直されるため）。

--ff-only

hint: Diverging branches can't be fast-forwarded, you need to either:
hint:   git merge --no-ff
hint: or:
hint:   git rebase
fatal: Not possible to fast-forward, aborting.

分岐していると、何もせずに止まりました。 手元で誤ってコミットしていないかを、毎回確かめたい人向けの設定です。

どれを選ぶか

rebase はコミットを作り直すので、すでに push して他の人が使っているコミットには使いません。 git の公式ドキュメントでも、他の人が使っているブランチを rebase で書き換えると、その人たちが履歴を直さなければならなくなる、と注意されています。merge と rebase の違い全体は、関連記事の「git mergeとrebaseの違い｜使い分けとコンフリクト解消」で扱っています。

毎回指定しないための設定

git config pull.rebase false     # このリポジトリだけ：merge
git config --global pull.rebase true    # すべてのリポジトリ：rebase

設定がぶつかって、まだ止まるとき

$ git config --show-origin --get-all pull.rebase
file:.git/config            false
$ git config --show-origin --get pull.ff
file:/home/.../.gitconfig   only

$ git pull
fatal: Not possible to fast-forward, aborting.

リポジトリで pull.rebase false（merge）にしたのに、--global に残っていた pull.ff only が効いて、止まりました。 以前にヒントのとおり3つとも試した、という場合に起きやすい形です。git config --show-origin で、どのファイルの設定かを確かめ、要らないほうを git config --global --unset pull.ff で消します。

rebase でコンフリクトしたとき

同じファイルの同じ行を、自分と他の人が変えていると、--rebase の途中で止まります。

Could not apply 7ed56ae... l2 a.txtを変更
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".

--abort で、pull する前の状態に戻せます。 落ち着いて merge でやり直す、という選び方もできます。コンフリクトの直し方は、関連記事の「Gitのコンフリクトの解消方法｜マーカーの読み方から防ぎ方まで」で扱っています。

確認の手順（チェックリスト）

よくある質問

Q. 手元のコミットが要らないときは。 A. 自分のコミットを捨ててリモートに合わせるなら git reset --hard origin/main ですが、コミットしていない変更も含めて消えます。消す前に git log origin/main..HEAD で、何を捨てるかを確かめます。誤って消したときの戻し方は、関連記事の「git reset --hardを取り消す方法｜reflogで復元する手順」で扱っています。

Q. git pull と git fetch の違いは。 A. git fetch はリモートの変更を取ってくるだけで、手元のブランチは変えません。git pull は、fetch のあとに merge か rebase を行います。このエラーは、その「あと」のやり方が決まっていないためです。違い全体は、関連記事の「git fetchとpullの違い｜図解とpull --rebaseの使い分け」で扱っています。

まとめ

• 手元とリモートの両方に、相手に無いコミットがあるときのエラー。何も変更されていない
• --no-rebase は merge（マージのコミットが増える）、--rebase は一直線（自分のコミットの ID が変わる）、--ff-only は止まる
• push 済みのコミットは rebase しない。まずチームの決まりを確かめる
• git config pull.rebase false・true で毎回の指定が不要に。--global との設定のぶつかりに注意
• rebase のコンフリクトは git rebase --abort で元に戻せる

参考・出典

確認日はいずれも 2026年10月11日です。

• Git Documentation「git-pull」：https://git-scm.com/docs/git-pull
• Git Documentation「git-rebase」：https://git-scm.com/docs/git-rebase

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。