MergeとSquash Mergeの違いとは？Git初心者向けに履歴の違い・使い分け・実際のIT現場での運用を分かりやすく解説
結論として、「Merge」はすべてのCommit履歴をそのまま残してブランチを統合する方法、「Squash Merge」は複数のCommitを1つにまとめてから統合する方法です。
GitHubやGitLabでPull Requestを作成すると、「Merge」「Squash and Merge」などの選択肢が表示されます。初心者は「どちらを選べばよいの？」と迷いがちですが、それぞれメリットと用途が異なります。
MergeとSquash Mergeとは？
Merge（通常のマージ）とは
Mergeは、開発ブランチのCommit履歴をそのまま保持した状態で、別のブランチへ統合する方法です。
例えば、開発中に5回Commitしていれば、その5回分の履歴がすべて残ります。
開発の経緯を詳しく残したい場合に適しています。
Squash Merge（スカッシュマージ）とは
Squash Mergeは、複数のCommitを1つのCommitへまとめてから統合する方法です。
例えば、5回Commitしていても、Merge後は「1回のCommit」として履歴に残ります。
履歴をシンプルに管理したい場合によく利用されます。
MergeとSquash Mergeの違い
| 項目 | Merge | Squash Merge |
|---|---|---|
| Commit履歴 | すべて残る | 1つにまとめられる |
| 履歴の見やすさ | 複雑になりやすい | シンプル |
| 作業経緯の確認 | しやすい | 詳細は分かりにくい |
| 主な用途 | 開発履歴を残したい場合 | 履歴を整理したい場合 |
| 初心者向け | ○ | ○（運用ルールを理解する必要あり） |
どんな場面で使われるのか
Mergeを使う場面
- 開発の経緯を残したい
- 障害調査で細かな変更履歴を確認したい
- 長期間の開発ブランチを統合する
- チームでCommit単位のレビューを行う
Squash Mergeを使う場面
- 細かいCommitが多い
- 履歴を見やすくしたい
- 機能単位で履歴を管理したい
- GitHub Flowなどの運用を採用している
初心者向けにイメージすると
| 操作 | イメージ |
|---|---|
| Merge | 作業メモをすべて保存して提出する |
| Squash Merge | 作業メモを1枚の報告書にまとめて提出する |
Mergeは作業途中も含めた履歴を残し、Squash Mergeは完成した成果だけを残すイメージです。
実際のIT現場での流れ
新機能を開発する場合の一般的な流れです。
- 作業用ブランチを作成する
- 機能を開発する
- Commitを複数回行う
- Pull Requestを作成する
- レビューを受ける
- MergeまたはSquash Mergeを実行する
- Deployする
チームによっては、すべてのPull RequestでSquash Mergeを採用するルールになっていることもあります。
なぜSquash Mergeが利用されるのか
開発中は「タイポ修正」「不要なファイルを削除」「コメント修正」など、小さなCommitを何度も行うことがあります。
そのままMergeすると履歴が見づらくなるため、Squash Mergeで1つにまとめることで、リポジトリを管理しやすくできます。
初心者が混乱しやすいポイント
Squash Mergeすると元のCommitが消えると思ってしまう
元のブランチにはCommit履歴が残っています。
ただし、統合先のブランチでは1つのCommitとして記録されます。
Mergeの方が必ず良いと思ってしまう
どちらが良いかはチームの運用ルールによります。
履歴を細かく残したいならMerge、履歴を整理したいならSquash Mergeが向いています。
GUIで確認する方法
GitHubの場合
- Pull Requestを開く
- 「Merge pull request」をクリックする
- 「Create a merge commit」または「Squash and merge」を選択する
- Commitメッセージを確認して実行する
利用できるマージ方法は、リポジトリの設定によって制限されている場合があります。
CUI（コマンド）で確認する方法
Commit履歴を確認
git log –oneline
Merge前後で履歴がどのように変わったか確認できます。
ブランチの履歴を確認
git log –graph –oneline –all
ブランチの分岐やMerge履歴を視覚的に確認できます。
確認結果の見方
| 状態 | 意味 |
|---|---|
| Merge Commit | 通常のMergeで作成されたCommit |
| Squashed Commit | 複数のCommitをまとめたCommit |
| Merged | ブランチが統合済み |
業務でよくあるトラブル
過去の細かな修正内容が分からない
原因
- Squash Mergeで履歴を1つにまとめた
- Commitメッセージが分かりにくい
確認する順番
- Pull Requestを確認する
- 元ブランチの履歴を確認する
- レビューコメントを確認する
- Commitメッセージを確認する
影響範囲
Merge方法を誤ると、履歴の見やすさや障害調査のしやすさに影響します。
ただし、ソースコード自体は適切にMergeされていれば、通常は動作に違いはありません。
筆者の現場経験
社内開発では、機能追加の途中で細かなCommitを何十回も行うことがありました。そのままMergeすると履歴が見づらくなるため、多くの案件ではSquash Mergeを採用していました。
一方で、インフラ構築や大規模な保守案件では、変更の経緯を細かく残す必要があり、通常のMergeを採用することもありました。プロジェクトの目的に応じて使い分けることが重要です。
新人がやりがちなミス
- チームのルールを確認せずMergeする
- Squash Merge後に履歴が変わったことに気付かない
- Commitメッセージを整理しない
- レビュー前にMergeする
- Merge方法の違いを理解せず操作する
現場で評価される確認手順
- Pull Requestを確認する
- Commit履歴を確認する
- チームのMergeルールを確認する
- レビュー完了を確認する
- 適切なMerge方法を選択する
- Merge後の履歴を確認する
上司へ報告するポイント
- Merge方法（MergeまたはSquash Merge）
- Pull Request番号
- 変更内容
- レビュー完了の有無
- Deploy予定
エスカレーションするタイミング
- どちらのMerge方法を使うべきか判断できない
- 誤ったMerge方法で統合した
- 履歴が想定と異なる
- 競合を解決できない
- レビュー手順に不明点がある
関連するIT用語
- Git
- Repository（リポジトリ）
- Commit
- Branch（ブランチ）
- Pull Request
- Rebase
- Cherry-pick
- Deploy
- Conflict（競合）
よくある質問（FAQ）
MergeとSquash Mergeではソースコードの内容は変わりますか？
通常は変わりません。違いは主にCommit履歴の残り方です。
どちらを使うべきですか？
チームの運用ルールに従うことが最も重要です。履歴を細かく残したい場合はMerge、履歴を整理したい場合はSquash Mergeが適しています。
Squash Mergeした後に元のブランチは削除できますか？
はい。Pull Requestが完了したブランチは、不要であれば削除することが一般的です。
Squash Mergeは履歴を書き換える操作ですか？
統合先では新しい1つのCommitが作成されるため、通常のMergeとは履歴の形が異なります。ただし、元のブランチのCommitが自動的に削除されるわけではありません。
まとめ
MergeとSquash Mergeはどちらもブランチを統合する方法ですが、Commit履歴の扱いが大きく異なります。
- Merge：すべてのCommit履歴を残して統合する
- Squash Merge：複数のCommitを1つにまとめて統合する
- 履歴を詳しく残したいならMerge、整理したいならSquash Merge
- IT現場ではチームの運用ルールに従ってMerge方法を選択することが重要
Gitを利用した開発では、Merge方法によって履歴の見やすさや保守性が変わります。それぞれの特徴を理解し、プロジェクトに適した方法を選択できるようになりましょう。