開発・エージェント

マージとは

この記事の結論

マージとは、分かれて進めた2つの履歴を1つに合流させる操作です。Gitは枝が分かれた地点を探し、両側の変更を突き合わせて1つにまとめます。
同じファイルの同じ場所を両方が書き換えていたときだけ、Gitは自動で決められません。これがコンフリクトで、印の入ったファイルを開き、残す内容に書き直してから記録し直すのが直し方です。
枝分かれの形をそのまま残して合流させるのがマージ、枝のコミットを本流の先へ付け替えて一直線にするのがリベース、枝の記録を1つにまとめて取り込むのがスカッシュマージです。

まーじ／Merge

分かれて進めた2つの履歴を、1つに合流させる操作のことです。

最終更新: 2026-09-17

マージとは何か（意味と読み方）

マージとは、ブランチに分かれて進めた2つの履歴を、1つに合流させる操作のことです。読み方は「まーじ」、英語では merge と書き、「併合する」「溶け合わせる」という意味の言葉です。

使う場面はほぼ決まっています。作業用の枝で機能を仕上げ、動くところまで確認できたので、本流の main に取り込む。このときに行うのがマージです。コミットが「変更を記録する」操作、マージは「分かれていた記録を1つに戻す」操作、と覚えると混ざりません。

チームで開発している場合、マージはプルリクエストの画面から行うことが多く、そこでは「マージ」ボタンを押す操作になります。手元で git merge を打つ場合も、起きていることは同じです。コマンドの正式な説明はgit-merge（git-scm.com）にまとまっています。

マージすると履歴はどうなるのか

Gitはまず、2つの枝が分かれた地点（共通の祖先）を探します。そのうえで、分かれてから両側で起きた変更を突き合わせ、1つの状態にまとめます。片方だけが触った場所はそのまま採用され、両方が触った場所だけが判断の対象になります。

合流のしかたは2通りあります。

早送り（fast-forward）：枝が分かれたあと、取り込み先がまったく動いていない場合。合流用の記録は作られず、名札を枝の先端まで進めるだけで終わります。
マージコミットを作る：両方が動いていた場合。合流専用のコミットが1つ作られます。このコミットだけは、1つ前が2つある（親が2つ）という形になります。

どちらの場合も、枝の上で作ったコミットは消えません。あとから履歴をたどれば、「どの枝で、いつ、何を変えたのか」は残ったままです。合流したあとで枝の名札を消しても、記録そのものは本流に残ります。

マージの基本的な手順

手元で合流させるときの流れは次の4段階です。取り込む先へ移動してから実行する、という向きを間違えないのが一番のポイントです。

手元でマージするときの手順
順番	やること	コマンドの例
1	取り込む先の枝へ移動する	`git switch main`
2	共有先の最新を手元に取り込む	`git pull`
3	作業用の枝を合流させる	`git merge feature/signup-email-check`
4	動作を確かめてから共有先へ送る	`git push`

2番目を飛ばすと、古い状態の上に合流させることになり、あとからプッシュを断られます。先に最新を取り込んでおくと、この手戻りが減ります。なお、合流の途中で「やっぱりやめたい」と思ったら、git merge --abort で合流前の状態に戻せます。

コンフリクト（衝突）が起きたときの直し方

コンフリクトは、同じファイルの同じ場所を、両方の枝が別々に書き換えていたときに起きます。どちらを残すべきかはGitには判断できないので、処理を止めて人に渡してきます。エラーではなく、判断を求められている状態です。

該当のファイルを開くと、次のような印が入っています。

<<<<<<< から ======= まで：いま自分がいる側の内容
======= から >>>>>>> まで：取り込もうとしている側の内容

直す手順は、(1) 印の入ったファイルを開く、(2) 最終的に残したい形に書き直す、(3) 印の3行を消す、(4) git add で解決済みにする、(5) git commit で確定する、の5段階です。

注意したいのは、どちらか片方を丸ごと選べば済むとは限らないことです。両側の変更がどちらも必要な場合もあり、そのときは2つを組み合わせた形に書き直します。片方を機械的に消すと、消した側の変更は履歴の上では合流したことになっているのに、中身は失われます。判断に迷ったら、その行を書いた人に確認するのが確実です。GitHub上での見え方と直し方はマージコンフリクトについて（GitHub Docs）に説明があります。

マージ・リベース・スカッシュマージの違い

「枝の変更を本流に取り込む」ためのやり方は1つではありません。履歴の残り方が違うので、場面で使い分けます。

マージ・リベース・スカッシュマージの違い
やり方	履歴の形	向いている場面
マージ	枝分かれと合流の形がそのまま残る	経緯を残したいとき。共有済みの枝を扱うとき
リベース	枝のコミットを本流の先端に付け替え、一直線になる	手元だけの枝を整えてから出すとき
スカッシュマージ	枝のコミットを1つにまとめて取り込む	細かい試行錯誤を本流に残したくないとき

リベースとスカッシュマージは、コミットを作り直しているという点が共通です。見た目はすっきりしますが、すでに共有した枝に対して行うと、他の人の手元と食い違います。共有済みの履歴には使わない、と決めておくのが安全です。取り込み方の選択肢はプルリクエストのマージについて（GitHub Docs）にも整理されています。

マージを使うときの注意点

合流の前に取り込み先を最新にする：古い状態の上で合流させると、送る段階でやり直しになります。
小さく、頻繁に合流させる：枝を長く抱えるほど、衝突する場所が増えます。
衝突を勘で消さない：消した側の変更は、履歴の上では取り込んだことになってしまいます。
合流したら動作を確かめる：両側とも単体では正しくても、合わせた状態で壊れることがあります。テストを通してから送ります。

合流まわりの動きを図で追いたい場合は、Pro Git 日本語版（git-scm.com）の「ブランチとマージの基本」の節が入口として読みやすい資料です。

よくある質問

Q1. マージとは何ですか？
分かれて進めた2つの履歴を1つに合流させる操作のことです。Gitは枝が分かれた地点を探し、そこから両側で起きた変更を突き合わせて1つの状態にまとめます。作業用の枝で作った機能を本流へ取り込むときに使います。

Q2. マージとプルリクエストは何が違いますか？
プルリクエストは「この枝を取り込んでください」と依頼し、レビューを受けるための仕組みです。マージは実際に合流させる操作そのものを指します。プルリクエストの画面でマージボタンを押すと、その場でマージが行われます。

Q3. コンフリクトはなぜ起きるのですか？
同じファイルの同じ場所を、両方の枝が別々に書き換えていたからです。どちらを残すべきかはGitには判断できないため、処理を止めて人に判断を求めます。壊れたわけではなく、選択を待っている状態です。

Q4. コンフリクトはどう直しますか？
印の入ったファイルを開き、最終的に残したい形に書き直してから、目印の行を消します。そのあと git add で解決済みにし、git commit で確定します。途中でやめたい場合は git merge --abort で合流前に戻せます。

Q5. マージとリベースはどう使い分けますか？
経緯を残したいときや、すでに共有している枝を扱うときはマージです。リベースはコミットを作り直して履歴を一直線にするので、他の人の手元と食い違う恐れがあります。手元だけの枝を整えるときに限って使うのが安全です。