Gitのマージとリベースの違い|AIに聞いて理解した記録

Gitのマージとリベースの違い|AIに聞いて理解した記録

「マージとリベースの違いがよくわからない」。Gitを使い始めると、一度はこの壁にぶつかりませんか。

私もそうでした。解説記事を読むと「リベースは履歴を書き換える」「マージはマージコミットを作る」と書いてあるのですが、言葉だけでは頭に入ってきません。そこで今回は、あえて検索せずにClaude Codeへ質問を重ね、さらに練習用フォルダで両方を実際に試して、違いを体で理解してみました。この記事では、そのときの質問プロンプトと、実際に見えた履歴の変化を公開します。

なお、この記事の内容はGit学習アプリの「マージ/コンフリクト」の章(章5・章8)とつながっています。記事末尾から、アプリで実際に手を動かせます。

Gitのマージとリベースの違いを一言でいうと

結論から言うと、違いは「履歴をどう残すか」です。

  • **マージ(merge)**:2本の道をそのまま残し、合流地点に「合流しました」という記録(マージコミット)を作る
  • **リベース(rebase)**:自分の道の作業を、相手の道の先端に「付け替え直して」、1本の道にする

どちらも「別のブランチの変更を取り込む」という目的は同じです。違うのは、取り込んだあとの履歴の形です。そして、リベースは付け替えるときにコミットを新しく作り直すので、「元のコミットがそのまま移動する」わけではありません。ここが一番のつまずきポイントでした。

調べずにClaude Codeへ聞いてみた

最初に私が貼ったのは、次のようなプロンプトです。


Gitのマージとリベースの違いを、Gitを使い始めたばかりの非エンジニア向けに説明してください。

目的: 違いを「履歴の形」でイメージできるようになりたい
範囲: 概念の説明だけ。私のリポジトリには何も変更を加えないでください
説明の条件:
- 専門用語を使うときは、たとえ話を1つ添えてください
- それぞれ「使うと何が起きるか」「気をつけることは何か」を分けてください
不明点は推測せず、確認事項として列挙してください。

返ってきた説明で一番わかりやすかったのは、「マージは2本の道が合流した地図をそのまま残す。リベースは自分の道を相手の道の先に引き直して、最初から1本道だったように見せる」というたとえでした。

ただ、正直に言うとこの時点ではまだ「ふーん」という感覚で、腹落ちはしていませんでした。そこで続けてこう聞きました。


さっきの説明を、実際に手元で確かめたいです。
練習用の新しいフォルダを作って、マージとリベースの違いが履歴で見える最小の手順を提案してください。

条件:
- 既存のリポジトリや作業中のフォルダには一切触れないでください
- 作成するフォルダ名と場所、実行するコマンドの一覧を先に表示し、私が確認してから実行してください
- ブランチ名やファイル名は英字にしてください
- ファイルの削除・上書き・マージ・リベースを実行する前に、対象と影響範囲を表示してください
不明点は推測せず、確認事項として列挙してください。

「練習用フォルダで」「既存のリポジトリには触れない」と明示しておくのが大事です。マージやリベースは、本番の作業フォルダでいきなり試すものではありません。

実際に試して見えた、マージとリベースの違い

Claude Codeの提案に沿って、練習用フォルダで次の状況を作りました(2026年9月時点、Git 2.33.0、macOSで確認。Gitのバージョンや環境によって表示が多少異なる場合があります)。

1. mainブランチで最初のコミット(A)を作る

2. featureブランチを作り、コミットを2つ(F1、F2)作る

3. mainに戻り、別のコミット(B)を作る

つまり「mainとfeatureが途中で枝分かれしている」状態です。ブランチの作り方は `git switch -c feature` を使いましたが、古い書き方の `git checkout -b feature` でも同じ結果になります(`git switch` はGit 2.23以降で使えるコマンドです)。

マージした場合

mainで `git merge feature` を実行し、`git log –graph –oneline –all` で履歴を見ると、こうなりました(コミットIDは伏せています)。


*   Merge branch 'feature'
|\
| * F2: 機能修正
| * F1: 機能追加
* | B: mainの更新
|/
* A: 最初

枝分かれした2本の線がそのまま残り、一番上に「Merge branch ‘feature’」という合流の記録が増えています。「何がいつ枝分かれして、いつ合流したか」がそのまま残る形です。

リベースした場合

同じ状況をもう一度作り、今度はfeatureブランチ上で `git rebase main` を実行しました。


* F2: 機能修正
* F1: 機能追加
* B: mainの更新
* A: 最初

枝分かれが消えて、1本の線になりました。F1とF2が、Bのあとに付け替えられています。

ただし、この時点で動いたのはfeatureブランチだけで、mainはまだBを指したままです。mainに取り込むには、このあとmainに移動して `git merge feature` を実行します。すでに1本の線になっているので、マージコミットは作られず、mainの目印がF2まで進むだけ(fast-forward)になります。なお、この最後の取り込み手順は今回の練習ではまだ試せておらず、Claude Codeの説明と公式ドキュメントをもとに書いています。

ここで「なるほど」と思ったのが、F2のコミットIDがリベースの前後で変わっていたことです。コミットの中身(メッセージや変更内容)は同じなのに、IDが別物になっている。Claude Codeに理由を聞くと、「リベースは元のコミットを移動させるのではなく、同じ変更を持つ新しいコミットを作り直すから」という説明でした。これは公式のGitドキュメント(Pro Git)にも書かれている仕組みです。

リベース中に衝突したら

もう1つ、わざと同じファイルの同じ行をmainとfeatureで書き換えてからリベースしてみました。すると「CONFLICT」と表示されて、リベースが途中で止まりました。

慌てそうになりましたが、`git rebase –abort` を実行すると、リベースを始める前の状態に戻りました。「途中でやめて元に戻せる」とわかっただけで、リベースへの怖さがかなり減りました。衝突そのものを解決する手順は、マージ・コンフリクトを自分で解決する記事で詳しく紹介しています。

リベースで気をつけること

リベースで一番大事なルールは、Claude Codeからも公式ドキュメントからも同じことを言われました。

すでにpushして、他の人も使っているブランチはリベースしない

リベースはコミットを作り直すので、他の人が持っている履歴と食い違ってしまいます。Atlassianのチュートリアルでも、公開ブランチでリベースしないことが、リベースで最も重要なルールとして説明されています。

私のような個人開発で、まだpushしていない自分だけのブランチなら、影響は比較的小さいと理解しています。ただ、チームでの運用経験はまだないので、「チーム開発でどこまでリベースしてよいか」は正直まだわかっていません。

実務での使い分け(squash mergeなど、GitHub上でのマージ方法の選び方)は、【連載⑧】Claude Codeのmerge&deployの流れでまとめているので、あわせて読んでみてください。

自分のリポジトリで試す前に使えるプロンプト

実際のリポジトリでマージやリベースをしたくなったときは、いきなり実行せず、次のように状況を確認してもらうのがおすすめです。


現在のリポジトリで、featureブランチの変更をmainに取り込みたいです。
マージとリベースのどちらが適しているか、判断材料を整理してください。

目的: 取り込み方法を安全に選びたい
対象: このリポジトリの現在のブランチと、main
確認してほしいこと:
- 現在のブランチ名と、未コミットの変更があるか
- このブランチがすでにリモートにpushされているか
- 取り込んだ場合に衝突しそうなファイルがあるか

マージ・リベース・pushなど履歴や変更に影響する操作は、実行前に対象ブランチ、コマンド、差分、影響範囲を表示してください。私が確認してから実行してください。
不明点は推測せず、確認事項として列挙してください。

ポイントは「判断材料を整理して」と頼み、実行は自分で確認してからにすることです。特にリベースやpushは取り消しが面倒になることがあるので、確認を挟む一文を必ず入れています。

この記事のまとめ

  • マージとリベースの違いは「履歴をどう残すか」
  • マージは枝分かれを残して、合流の記録(マージコミット)を作る
  • リベースは作業を付け替えて1本の履歴にし、コミットは新しく作り直される
  • リベース中に衝突しても、`git rebase –abort` で開始前の状態に戻せた
  • pushして他の人も使っているブランチはリベースしない

言葉だけで理解しようとしていたときより、練習用フォルダで一度試したほうが、ずっと早く腹落ちしました。「違いがわからない」と感じている方は、まずは上のプロンプトで、壊しても困らない場所から試してみてください。

このトピックをアプリで試す

この記事の内容は、Git学習アプリの「マージ/コンフリクト」の章(章5・章8)で、本物のターミナルを使って手を動かしながら確認できます。

Git学習アプリで実際に試す(GitHubで無料公開中)

> アプリはGitHub上でコードを公開しており、ローカル環境にcloneして動かす形式です(2026年9月時点)。Webアプリ版は `app.maahsachi.com` で公開準備中です。

アプリの紹介は本物のターミナルでGitを学べる学習アプリを作りましたにまとめています。ブランチの基本から復習したい方はブランチは”もう一本の道”の記事もどうぞ。

参考情報(2026年9月時点で確認)

  • [Git – Rebasing(Pro Git)](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)
  • [Git – git-rebase Documentation](https://git-scm.com/docs/git-rebase)
  • [マージとリベース|アトラシアン Git チュートリアル](https://www.atlassian.com/ja/git/tutorials/merging-vs-rebasing)
maah

この記事を書いた人

maah

非エンジニア。日々の業務にClaudeを取り入れた実体験を、初心者の目線で発信しています。