Gitのsquashとは？コミット履歴を整理する基本操作と活用事例

Gitで「細かいコミットが多すぎて見づらい」「PR前に履歴を整理したい」と悩んだことはありませんか？

この記事では、コミットを1つにまとめるsquashの基本操作から活用シーン、注意点までを初心者にもわかりやすく解説します。実際の開発フローにどう役立つのかを具体的な事例とともに紹介します。

初心者でもできる！squashの基本手順（対話式rebase）

✅ 前提の状況

この記事では以下のようにブランチが階層的に存在している前提で解説します。

main
 └── mybranch1
       └── mybranch2
             └── mybranch3

例えば、mybranch3で作業中の複数コミットを1つにまとめたい場合は、mybranch3に切り替えて作業します。

squashとは、複数のコミットを1つにまとめるGit操作のことです。主にgit rebase -i（対話式rebase）を用いて行います。

✅ 事前準備：Git Bashで作業ブランチを確認する（必要に応じてブランチを移動）

1. Git Bashを起動します。
2. プロジェクトフォルダに移動します。

   cd path/to/your/project
   
   

3. 現在のブランチと履歴を確認します。

   git branch
   
   

   現在の作業ブランチに「*」が付いています。

git log --oneline

✅ squashが完了したら、上記のコマンドでコミット履歴が正しく整理されているか確認しましょう。

このコマンドで、対象のコミット数や内容を事前に確認しておくと安心です。

もし現在のブランチがsquashしたい対象ブランチでない場合は、以下のようにブランチを切り替えてください：

git checkout 対象ブランチ名

✅ 1. 作業用ブランチの作成と準備

mainブランチから作業ブランチを作成し、mybranch3をマージします。

squash作業の前に、mainブランチから新たな作業用ブランチ（例：mybranch3rebase）を作成し、そこにmybranch3を一度マージしておくと、後のマージ競合を減らせる可能性があります。

git checkout main
git pull origin main

git checkout -b mybranch3rebase  # -bオプションは新しいブランチを作成し、同時にそのブランチに切り替える
git merge mybranch3

これで、mybranch3の変更を含んだ作業ブランチmybranch3rebaseができます。

このブランチ上で、まとめたいコミット数を指定してrebaseを開始します：

HEAD~3とは、「現在のブランチ（HEAD）から数えて過去3件分のコミット」を意味します。対象のコミット数に応じて、この数字を変更してください。

また、-iオプションは「インタラクティブ（対話式）」の意味で、コミットの操作内容（pickやsquashなど）をエディタで選択できるようになります。

💡 HEAD~3は、「直近の3件を対象にしたい」という意味です。

数字を変えることで、まとめたい件数を自由に指定できます。

例：

• 2件まとめたい → HEAD~2
• 5件まとめたい → HEAD~5

どのくらい過去まで戻るかは、事前にgit log --onelineなどで確認してから設定しましょう。

git rebase -i HEAD~3

※この例では「直近3件のコミット」を対象にしています。必要な数に応じて変更してください。

✅ 2. 対話画面で「pick」を「squash」に変更

git rebase -iを実行すると、デフォルトでは vim エディタが起動します（設定によっては他のエディタの場合もあります）。

📌 vimでの基本操作：

• dd：行全体を削除します（削除したい行で dd を押します）。
• キーボードの i を押すと編集モードに入ります。
• pick の文字を squash に書き換えます（または s でも可）。
• 編集が完了したら、Esc を押してノーマルモードに戻ります。
• :wq と入力して Enter を押すと保存＆終了され、次のステップへ進みます。

※ もし vim の操作に慣れていない場合は、GIT_EDITOR 環境変数を使って別のエディタ（例：Visual Studio Code）を指定することもできます：

GIT_EDITOR=code git rebase -i HEAD~3

※ code コマンドが使えない場合は、Visual Studio Codeの「コマンドパレット」から Shell Command: Install 'code' command in PATH を実行してください。

以下のような画面がエディタに表示されます：

次のような画面がエディタに表示されます：

pick 1234abc 最初のコミット
pick 5678def 修正1
pick 90abcd2 修正2

1つ目の行はそのままにし、2つ目以降をsquashまたはsに変更します。

pick 1234abc 最初のコミット
squash 5678def 修正1
squash 90abcd2 修正2

✅ 3. 統合後のコミットメッセージを編集

次の画面で、新しいコミットメッセージを記述します。

feat: 新機能を追加（UI調整・バグ修正含む）

メッセージを保存・終了すると、rebaseが続行されます。

✅ 4. mybranch3rebaseのrebase完了後にforce push（必要な場合）

履歴が書き換わったため、リモートと差分が発生します。

git push -f origin mybranch3rebase

✅ 5. squash済みブランチをmainにマージする

squashして整理したmybranch3rebaseブランチをmainにマージするには、以下の手順を実行します：

git checkout main
git pull origin main  # 最新の状態に更新

git merge mybranch3rebase

マージ後、mainブランチの内容をリモートにも反映させます：

git push origin main

🔧 マージ時に競合が発生した場合の対応手順

1. 競合のあるファイルが表示されるので、それらをエディタで開いて内容を確認・解消します。
2. 競合部分は以下のようなマーカーで囲まれています：

   <<<<<<< HEAD
   現在のmainの内容
   =======
   mybranch3rebase側の内容
   >>>>>>> mybranch3rebase
   
   

3. 必要な内容を残して不要な部分とマーカーを削除し、保存します。
4. 修正したファイルをステージングします：

   git add 修正したファイル名
   
   

5. コンフリクト解消後、マージを完了します：

   git commit
   
   

6. その後、mainブランチをリモートにpushします：

   git push origin main
   
   

✅ 競合解消が難しい場合は、チームメンバーと相談して適切な方針で対応しましょう。

✅ 必要に応じてPull Request（PR）を使ってレビュー・マージする運用も可能です。

PR前の神ツール！squashが役立つ場面と注意点

※ここでの「PR」とは「Pull Request（プルリクエスト）」の略です。GitHubやGitLabなどのリモートリポジトリで、変更を他の人にレビューしてもらったり、mainブランチにマージを依頼するための仕組みです。

squashが役立つ主な場面

✅ 1. PR作成前に履歴を整理したいとき

複数のコミットを1つにすることで、レビュアーが内容を把握しやすくなります。

✅ 2. 細かい修正を機能単位でまとめたいとき

スペル修正・コメント追記など細かなコミットが多くなった場合に有効です。

✅ 3. チームの履歴ルールを守るため

「1機能1コミット」などのルールがあるチームでは必須です。

squashの注意点

⚠ 履歴改変の影響に注意

squashを行うとコミットIDが変更されるため、以下のような影響があります：

• 他の開発者がpull/push時にコンフリクト
• CI/CDがコミットハッシュを参照しているとビルドエラー

事前にチームと相談し、適切なタイミングで操作しましょう。

補足：squashの影響を可視化（Mermaid図）

graph TD
  A[ローカルブランチ] -->|git push -f| B[リモートブランチ]
  B --> C[他の開発者のローカル]
  C -->|pull時| D[コンフリクト発生の可能性]

実践で使える！PR前にsquashを使うベストタイミングとは？

✏️ ケース：新機能ブランチでの開発中にコミットが増えた

開発中、以下のようなコミットを重ねたとします：

[add] 新機能の追加
[fix] バグ修正
[refactor] コメント整理

このままではPRが見づらくなるため、次のようにsquashします：

git rebase -i HEAD~3

pick 1234abc 新機能の追加
squash 5678def バグ修正
squash 90abcd2 コメント整理

変更後のコミット：

feat: 新機能の追加（バグ修正・整理含む）

✏️ 明瞭な履歴でチームの信頼度アップ

履歴が簡潔になることで、レビュアーやメンテナの理解が深まり、チーム内の信頼・レビュー効率向上につながります。

よくある失敗と回避策

• 対象のコミット数を間違える → git log --onelineで事前に確認
• squash後にpushし忘れる → pushの手順をメモ化
• squash直後にCIが失敗 → CIの設定確認をルール化

よくある質問（FAQ）

Q. squashはいつ行うべき？

A. 通常はPRを出す直前、最終確認のタイミングで行うのが理想です。

Q. squash後のコミットIDが変わるのはなぜ？

A. rebaseは履歴を書き換える操作なので、squashによって新しいコミットとして扱われるためです。

Q. force pushはなぜ危険なの？

A. 既に共有済みのブランチの履歴が書き換わることで、他の開発者のpull/push時に競合を引き起こす可能性があるためです。実行前にはチームの合意を得るようにしましょう。

まとめ

Gitのsquashは、コミットを整理し、保守性とレビュアビリティを向上させる強力なツールです。

✅ squashを活用すべきタイミング：

• PR前に履歴を整理したいとき
• 細かい修正をまとめたいとき
• 履歴管理ルールに従う必要があるとき

⚠ squashはforce pushを伴う可能性があるため、慎重に使いましょう。

開発フローの中でsquashを使いこなすことで、綺麗で分かりやすい履歴を残し、チーム開発の品質を一段上に引き上げることができます。

ぜひこの機会に、あなたの開発フローにもsquashを積極的に取り入れてみてください。