章: 第5章: 変更履歴を実務で整える
作業中のコミット数と、本流に残したい履歴数は同じとは限らない
実務では、作業中に細かくコミットを積むことがあります。
- 途中保存のコミット
- レビュー指摘への小さな修正
- 一時的な調整コミット
これは作業中としては自然です。しかし、そのまま本流へ全部並べると、あとから履歴を読む人には少しノイズになります。
そこで使われるのが squash merge です。
squash merge は、複数のコミットを1つにまとめた形で本流へ取り込む方法です。
なぜ使うのか
プルリクエストの中では10コミットあったとしても、「本質的にはログインバリデーション追加」という1テーマなら、本流には1件として残したいことがあります。
そうすると履歴がかなり読みやすくなります。
つまり squash merge は、作業中の細かい履歴と、本流に残したい履歴を分けて考えるための方法です。
どういう場面に向いているか
- 1つのプルリクエストが1つの目的にきれいにまとまっているとき
- レビュー修正コミットが多く、本流へは要点だけ残したいとき
- 本流の履歴をできるだけ簡潔に保ちたいとき
たとえば次のようなコミットが並んでいたとしても、
feat: ログイン時の入力チェック追加fix: レビュー指摘で命名修正fix: テストケース追加
本流では「ログイン時の入力チェック追加」として1件にまとめた方が読みやすい場合があります。
通常の merge との違い
| 取り込み方 | 本流にどう残るか |
| 通常の merge | ブランチ上のコミットがそのまま残りやすい |
| squash merge | まとめられた1コミットとして残る |
ここで大事なのは、squash merge は「作業履歴を消す」というより、「本流に残す単位を整える」ことだと理解することです。
実務での考え方
チームによっては「PRは squash merge で統一」という運用も珍しくありません。
理由は単純で、
mainの履歴が読みやすい- 1PR = 1コミットで意味が追いやすい
- レビュー修正の細かいノイズを本流へ残しすぎない
という利点があるからです。
ただし、細かな途中経過まで本流に残したい場合は通常 merge の方が向くこともあります。ここも運用次第です。
チェックポイント:
squash mergeは「コミットを減らす技術」ではなく、「本流に残す意味の単位を整える技術」と考えましょう。
まとめ & 次のステップ
squash mergeは複数コミットを1つにまとめて取り込む方法- 作業中の履歴と本流に残したい履歴を分けて考えられる
- PR単位で履歴を簡潔に保ちたいときに向いている
- 本流の可読性を重視するチームでよく使われる
- merge 方法はチーム方針と履歴の残し方で選ぶ
次回は revert を扱います。 実務で「変更を取り消したい」ときに、なぜ reset ではなく revert が選ばれることが多いのかを整理します。
