メインコンテンツへスキップ

Squash and merge とは何か ― Pull Request運用を壊さないための実践ガイド

📝 はじめに

本記事では、GitHub の Pull Request（PR）マージ方式の一つである Squash and merge について、 「それは何か」「なぜ使うのか」「いつ使うべきで、いつ避けるべきか」を チーム開発の実務視点 で整理します。

対象読者は以下を想定しています。

  • 数人規模（2〜6人程度）のチーム開発
  • feature / fix ブランチを使ったPR運用
  • Git履歴を「後から読む資産」として扱いたい人

🔍 Squash and merge とは

📌 定義

Squash and merge とは、

Pull Request 内の複数コミットを 1つのコミットにまとめてから マージする方式

です。

GitHub の PR マージ時に選択できる3方式のうちの1つです。

🧠 何が起きるのか（具体例）

PR に次のようなコミットが含まれていたとします。

commit A: add CSV export logic
commit B: fix typo
commit C: address review comments

これを Squash and merge すると、 main / develop 側には次の 1コミットだけ が残ります。

commit X: add CSV export feature

A〜C の内容はすべて含まれますが、履歴上は 1コミットとして整理されます

🎯 なぜ Squash and merge を使うのか

✅ 理由1：本流の履歴を「意味の履歴」にするため

開発中のコミットには、次のようなものが必ず含まれます。

  • 試行錯誤
  • レビュー対応
  • 微修正
  • 一時的に壊れた状態

これらは 開発過程としては重要 ですが、 本流の履歴としては価値が低い ことがほとんどです。

Squash は「過程」と「成果」を分離するための仕組みです

✅ 理由2：「1 PR = 1 意味」を保証できる

Squash and merge を使うと、

  • PRタイトル
  • PR説明

が、そのまま 1コミットの説明 になります。

結果として Git履歴は、

何を追加したか
何を修正したか
なぜ入れたか

が並ぶ 読み物としての履歴 になります。

✅ 理由3：コミット粒度の議論を不要にする

Squash 前提にすると、

  • 開発中は自由にコミットしてよい
  • 試行錯誤やWIPコミットを気にしなくてよい

という状態を作れます。

開発の自由度と、履歴の美しさを両立できます

🔀 他のマージ方式との違い

🔸 通常の merge（Create a merge commit）

  • PR内のコミットが すべて本流に残る
  • 試行錯誤も履歴に残る

小規模〜中規模チームでは、履歴が急速に読めなくなりがちです

🔸 Rebase and merge

  • 各コミットをそのまま本流に積み直す
  • 履歴は直線になるが、粒度はそのまま

ライブラリ開発や、履歴粒度が重要な場合に向く方式です

🔸 Squash and merge

  • PR全体を1コミットに圧縮
  • 本流は「意味の一覧」になる

アプリケーション開発では最も扱いやすい方式です

📐 いつ Squash and merge を使うべきか

👍 Squash が適しているケース（原則こちら）

  • feature / fix ブランチ
  • 試行錯誤が多いPR
  • 「このPRは1つの変更」と説明できる

中規模以下のPythonプロジェクトでは、原則 Squash が最適解です

⚠️ Squash を避けた方がよいケース

  • 各コミットが独立した意味を持つ
  • 将来、特定のコミットだけを revert したい
  • OSS / ライブラリ開発で履歴粒度が重要

無理に Squash すると、逆に履歴の価値を下げる場合もあります

📝 Squash and merge 時の注意点

✏️ コミットメッセージは「PRの要約」

Squash 時に作られるコミットメッセージは重要です。

推奨

  • PRタイトル：簡潔・動詞始まり
  • PR本文：Why / 仕様 / 注意点

Squash後のコミットは「この変更の公式説明」になります

🚫 よくある誤解

❌ 「Squashすると履歴が消える」

→ 消えません

  • PR内の詳細は GitHub 上に残る
  • 本流には整理された履歴が残る

❌ 「細かくコミットしてはいけない」

→ 逆

Squash 前提だからこそ、安心して細かくコミットできます

🧯 アンチパターン

❌ SquashしないのにWIPコミットだらけ

本流の履歴が作業ログになり、誰も読まなくなります

❌ SquashするのにPR説明が空

後から「なぜこの変更が入ったか」が分からなくなります

✅ まとめ

  • Squash and merge は 履歴を壊さずにチーム開発を回すための仕組み
  • 「PR中は自由、本流は整理」が基本思想
  • 中規模Pythonプロジェクトでは 原則 Squash が最適解
  • 重要なのは「使う／使わない」ではなく 方針を統一すること

Squash and merge は、Git運用を楽にしつつ、将来の自分を助ける投資です

上に戻る