スカッシュマージ：Git履歴を効率的に整理する方法

Git を使って開発を進める際、コミット履歴が煩雑になってしまうことはよくあります。そんなときに便利なのが スカッシュマージ（Squash Merge） です。本記事では、スカッシュマージのメリットや使い方を解説します。

スカッシュマージとは？

スカッシュマージとは、ブランチをマージする際に 複数のコミットを1つにまとめて 取り込む方法です。通常のマージでは個々のコミットがそのまま残りますが、スカッシュマージを使うと履歴がスッキリします。

スカッシュマージのメリット

スカッシュマージは単に履歴を整理するだけでなく、開発の効率性と保守性を大幅に向上させる手法です。特にチーム開発において、その真価を発揮します。

コミット履歴が整理される

不要な「修正」や「調整」コミットがなくなり、履歴が見やすくなります。開発者が本質的な変更に集中でき、履歴を追跡する際の認知負荷が軽減されます。

レビューがしやすい

大量の細かいコミットを追う必要がなく、変更内容を簡単に把握できます。レビュアーは機能やバグ修正の全体像を一度に理解でき、より効率的で質の高いコードレビューが可能になります。

バグ追跡・原因特定が容易

Issue単位でコミットがまとめられているため、バグが発生した際に「どの機能追加・修正が原因か」を素早く特定できます。

具体例：

「ログイン機能のバグ修正 (#123)」というコミットがあれば、そのコミット前後での動作比較が簡単
細かいコミット（「typo修正」「スペース調整」など）に惑わされることなく、本質的な変更箇所を追跡可能
問題のある変更をリバート（取り消し）する際も、Issue単位でまとまっているため、関連する変更を漏れなく元に戻せる

この利点は、特に本番環境でのトラブルシューティング時や、複雑なバグの原因究明において非常に価値があります。

チーム開発がスムーズに

きれいな履歴は、他の開発者が理解しやすく、共同作業がしやすくなります。新しいチームメンバーが参加した際も、プロジェクトの変更履歴を迅速に把握できるため、オンボーディングが効率化されます。

スカッシュマージのデメリット

スカッシュマージはコミット履歴を整理し、開発フローを効率化する便利な手法ですが、いくつかのデメリットも存在します。以下に、具体的なデメリットとその影響について説明します。

コミット履歴の消失による作業の形跡の喪失

スカッシュマージを行うと、ブランチ内の個々のコミット履歴が1つのコミットにまとめられ、詳細な履歴が失われます。これにより、以下のような影響が考えられます：

作業の形跡が消える: 開発中にどのような変更が段階的に行われたか（例: 「初期実装」「バグ修正」「コード最適化」など）がわからなくなります。後から特定の変更を追跡したい場合に、詳細なコンテキストが失われるため、デバッグや問題の原因究明が難しくなる可能性があります。
複数人での作業における影響: チームでブランチを共有し、複数人でコミットしていた場合、個々の貢献者のコミットが統合されてしまい、誰がどの変更を担当したかが不明瞭になります。これにより、協力者の貢献が見えづらくなることがあります。

コミット内容を評価指標にしている場合の影響

一部の組織では、コミット数やコミット内容を個人の評価指標として利用する場合があります。スカッシュマージを採用すると、個々のコミットが消滅するため、以下のような課題が生じます：

評価の難しさ: コミット履歴をベースにした評価ができなくなります。例えば、コードの変更量や頻度で貢献度を測る場合、スカッシュマージによりそのデータが失われます。
ただし、これは稀なケース: 実際には、コード変更量の多さ＝功績とみなす評価方法を採用している組織は少数です。ほとんどのチームや組織では、Issueの完了内容やプルリクエストの質、プロジェクト全体への貢献度をもとに評価を行っています。コード量やコミット数に依存した評価は、実際の成果を正確に反映しないため、適切ではないとされることが一般的です。

よくあるスカッシュマージの誤解

よくある誤解 「スカッシュマージを使うと、子ブランチをマージする際にコンフリクトが発生しやすくなる」「コミットハッシュが変わることでGitが混乱してコンフリクトが起きる」

実際のところ スカッシュマージ自体がコンフリクトを引き起こすわけではありません。コンフリクトが発生するのは、同じファイルの同じ箇所に競合する変更がある場合のみです。

コンフリクトが発生する本当の原因

複数のブランチが同じファイルの同じ行を変更している
mainに他のPRがマージされていて、その変更と競合している
つまり、通常のGitマージで起こる一般的なコンフリクト

コンフリクトが発生しない場合

スカッシュマージされた変更と、子ブランチの変更に実質的な差がない
他に競合する変更がmainに含まれていない
この場合、マージ方法に関係なくコンフリクトは発生しません

よくある誤解の具体例

親ブランチ（main）から子ブランチ（feature/A）、さらに孫ブランチ（feature/B）を作成し、子ブランチを親ブランチ（main）にスカッシュマージすると、コミットハッシュが変わることでGitが混乱し、孫ブランチをマージする際にコンフリクトが発生する

なぜこの理解が間違っているか

コミットハッシュの変更はコンフリクトの直接的な原因ではありません
実際にコンフリクトが起きるのは、ファイル内容に競合がある場合のみ
例：親ブランチでファイルAを変更、その後mainに他の変更が加わってファイルAが再度変更された場合など
スカッシュマージの有無に関係なく、同じファイルへの競合する変更があればコンフリクトします

スカッシュマージの活用方法

ここでは代表的なブランチ管理方法における、スカッシュマージの活用方法について説明します。

Issue 単位で PR を作成してマージ

Issue 単位でプルリクエスト (PR) を作成し、スカッシュマージを行うことで、Issue とコミットの関連性を明確にすることができます。これにより、履歴を追いやすくなり、リリースの内容も整理されて分かりやすくなります。

重要なポイント：

開発中のマージ: 機能ブランチ間での作業中は通常のマージを使用し、詳細な履歴を保持する
最終マージ: mainブランチやdevelopブランチへの統合時のみスカッシュマージを使用する

そもそも、機能ブランチの細かいコミットは開発完了後は不要です。Issue 単位でコミットをまとめることで十分であり、開発履歴がシンプルになり、チーム全体の開発効率が向上します。

Git Flow でのスカッシュマージ

Git Flow では、機能ブランチ (feature branch) から develop ブランチへ統合する際にスカッシュマージを使用すると、個々の機能開発中の細かいコミットを整理し、開発履歴をシンプルにできます。

開発中のブランチ間でのマージは通常のマージを使用し、developブランチへの最終的な統合でのみスカッシュマージを活用することで、作業履歴を保持しながら最終的な履歴を整理できます。

GitHub Flow でのスカッシュマージ

GitHub Flow では、短期間での開発を前提としており、プルリクエスト (Pull Request) をメインブランチにマージする際にスカッシュマージを利用すると、履歴を一つのまとまりとして管理しやすくなります。特に、頻繁なブランチ作成とマージを行う場合に効果的です。

GitHub Flowでは基本的にメインブランチへの直接マージとなるため、プルリクエスト作成時にスカッシュマージを選択することで、機能単位での履歴管理が実現できます。

スカッシュマージの使い方

GitHubのプルリクエストおよびコマンドラインを使ったスカッシュマージの方法を説明します。

GitHub の場合

GitHub のプルリクエストでスカッシュマージを行うのは簡単です。

プルリクエストを開く
「Squash and Merge」ボタンをクリック
コミットメッセージを編集して「Confirm」

コマンドラインの場合

ローカル環境でスカッシュマージをするには、以下の手順を実行します。

# 対象ブランチにチェックアウト
$ git checkout main

# スカッシュマージ
$ git merge --squash feature-branch

# まとめた変更をコミット
$ git commit -m "まとめた変更のメッセージ"

# リモートにプッシュ
$ git push origin main