GitHubでプルリクエストをマージするときに出てくる、「Squash and merge」というボタン。
なんとなく押しているけれど、普通の「Merge」と何が違うのか？
「とりあえず Squash にしておけば良いと聞いたけど、本当に大丈夫？」
とモヤモヤしている方も多いのではないでしょうか。
この記事では、GitHubのマージ方法のひとつであるSquash and mergeについて、
- 何が起きているのか（仕組み）
- どんなメリット・デメリットがあるのか
- 小〜中規模チームでのおすすめ運用例
をコンパクトに整理していきます。
Contents
Squash and mergeとは？
Squash and mergeは、プルリクエストをマージするときに、作業ブランチ側の複数のコミットを1つにまとめてから main ブランチへ取り込むマージ方法です。
たとえば開発中のブランチで、次のようなコミットをしていたとします。
- WIP: ヘッダー調整中
- fix: 余白のズレを修正
- refactor: CSS を共通化
- fix: スマホだけ崩れていたのを修正
このブランチを Squash and merge すると、main ブランチ側ではこれらのコミットがまとめて、
feat: ヘッダーのデザイン調整
という1つのコミットに変換されてから取り込まれます。
GitHub上では、プルリク作成画面で設定したタイトルと説明を元に、
この「まとめコミット」のメッセージを編集してからマージすることができます。
Squash and mergeのメリット
Squash and merge の大きなメリットは、mainブランチの履歴がスッキリすることです。
1. mainブランチの履歴が「PR単位」で見やすい
通常の Merge commit だと、作業中の細かいコミットも main にそのまま流れ込みます。
すると、WIP や fix typo のようなコミットが大量に並んでしまい、
あとから git log を見ても「どのコミットがどんな機能追加なのか」が分かりづらくなります。
Squash and merge なら、
- 1つのプルリクエスト = 1つのコミット
という形で履歴を残せるので、あとから履歴を追うときに、
- このコミットで「ログイン画面のデザイン調整」をやっている
- このコミットで「お問い合わせフォームのバリデーション追加」をしている
といったことが一目で分かるようになります。
2. 試行錯誤のコミットを main に持ち込まなくて済む
開発中はどうしても、次のようなコミットが増えがちです。
- debug: console.log 追加
- 一時的にバリデーションをコメントアウト
- レイアウト崩れの試し実装
こういったコミットは、開発中には役に立つけれど、本番用の履歴としてはあまり意味がないものです。
Squash and merge を使えば、こうした細かいコミットはプルリクの中だけに閉じ込めておき、
main には「最終的な結果として何をしたのか」だけを綺麗に残すことができます。
3. 問題があったときにまとめて戻しやすい
もし「このプルリクで入れた変更をまるっと戻したい」という状況になったとき、
Squash and merge されていれば、main上のその1コミットだけを revert すればOKです。
細かく分かれたコミットを1つずつ戻す必要がないので、
運用上もシンプルで安全です。
Squash and mergeの注意点・デメリット
一方で、Squash and merge にはいくつか注意したいポイントもあります。
1. main側には「細かいコミット」は残らない
mainブランチから履歴を見たときに、
開発中の細かいコミット単位での変更内容は追えなくなります。
ただし、プルリクの画面を見れば元のコミット履歴や差分は確認できるため、
実務上はそこまで困らないケースが多いかな…という印象です。
2. ローカルのブランチとはコミットハッシュが変わる
Squash and merge すると、main側には「新しい1コミット」が作られるので、
ローカルで作業していたブランチのコミットハッシュとは別物になります。
基本的な運用としては、
- プルリクがマージされたら、その作業ブランチは削除する
- 次の作業をするときは、また main から新しくブランチを切る
という形にしておくと、履歴のズレで混乱しにくくなります。
3. プロジェクトによっては好まれないケースもある
OSS や一部の開発チームでは、
- コミット単位で貢献を見たい
- 細かいコミットログも履歴として残しておきたい
といった方針から、あえて通常の Merge commit を使っているところもあります。
そのため、既にチームやプロジェクトのルールが決まっている場合は、まずはその運用に従うのが基本です。
小〜中規模チームでのおすすめ運用例
これから GitHub を本格的に使い始める小〜中規模の開発チームであれば、
個人的には「基本は Squash and merge」という方針をおすすめしています。
具体的には、次のようなルールイメージです。
- mainブランチは本番用として常に安定させておく
- 作業は
feature/○○やfix/○○といったブランチで行う - プルリクが承認されたら、Squash and merge で main に取り込む
- マージ後、その作業ブランチは削除する
こうしておくと、
- main の履歴がシンプルで追いやすい
- 万が一のときもコミット単位で戻しやすい
- Git にまだ慣れていないメンバーにも説明しやすい
といったメリットがあり、最初の一歩としてちょうどよいバランスかなと感じています。
よくある疑問Q&A
Q. とりあえず全部 Squash and merge にしておいて大丈夫？
自社サービスや社内システムのように、チーム内だけで完結するプロジェクトであれば、
基本的には Squash and merge ベースで問題ないことが多いです。
ただし、OSS のように外部からのコントリビュートを受けるプロジェクトでは、
プロジェクト側のルールが決まっていることが多いので、まずは運用ルールを確認しましょう。
Q. 途中で通常の Merge commit に切り替えてもいい？
はい、構いません。プロジェクトの成長に合わせて、
「細かい履歴も残したい」「リリース単位でまとめてマージしたい」など、
運用方針が変わることもよくあります。
大事なのは、チーム全体で同じルールを理解していることなので、
ルールを変えるときは軽くでも良いので共有しておくと安心です。
Q. 間違って Squash and merge してしまった場合は？
状況によって対処は変わりますが、
本番環境に影響するような変更を誤ってマージしてしまった場合は、
1人で無理に戻そうとせず、チームで相談しながら対応するのが安全です。
内容によっては revert で戻せることもあれば、
改めて修正用のブランチを切って対応した方が良い場合もあります。
まとめ：まずは「Squash and merge」を基本にしてみる
今回は、GitHubのマージ方法のひとつであるSquash and mergeについて、
- どんなマージ方法なのか（何が起きているのか）
- メリット・デメリット
- 小〜中規模チームでの運用例
- よくある疑問Q&A
をざっくり整理しました。
GitHubのマージ方法は色々ありますが、
まだ運用ルールが固まっていない段階では、
- 基本は Squash and merge を使う
- main の履歴を「PR単位」で見やすく保つ
- マージ後は作業ブランチを削除し、次の作業は main から切る
といったシンプルな方針からスタートしてみるのがおすすめです。
プルリク運用全体の流れや、他のマージ方法との比較については、
別記事の「GitHubプルリクエスト実践ガイド」もあわせて読んでいただくと理解が深まると思います。
新着情報
ブログランキングに参加しています。クリックして応援していただけると嬉しいです。
