1. ホーム
2. web
3. Git Squash Merge：チームのためのクリーンな履歴戦略

はじめに

Gitの履歴はチームと未来の自分自身のためのコミュニケーションツールです。クリーンで読みやすい履歴は、デバッグ、コードレビュー、リリース管理を大幅に容易にします。Squash Mergeはクリーンな履歴を維持する主要な戦略の1つですが、いつ、どのように使用するか、いつ代替手段を選ぶべきかを理解するには、各手法のトレードオフを把握する必要があります。

Squash Mergeの仕組み

Squash Mergeはフィーチャーブランチのすべてのコミットをターゲットブランチ上の単一のコミットに結合します。フィーチャーブランチにコミットC、D、Eがある場合、マージ後は1つのコミットHとして統合されます。

git merge --squash feature-branch
git commit -m "feat: ユーザー認証を追加"

主な特性：

• 個々のコミットは1つにまとめられる
• フィーチャーブランチ自体はマージされない（マージコミットなし）
• 元のコミット履歴はフィーチャーブランチに保持される
• 新しいコミットには新しいメッセージを指定する

Squash vs Merge vs Rebase

各戦略は異なる目的に役立ちます。

Squash mergeは、個々のコミットがWIPや乱雑な場合、各フィーチャーが1つの論理ユニットであるべき場合、メインブランチでコミット単位の帰属が必要ない場合に適しています。通常マージは各コミットが意味を持ちアトミックな場合や、複数の共同作業者がブランチで作業した場合に使用します。

GitHubのSquash Merge設定

GitHubはリポジトリ設定のMerge buttonセクションでsquash mergeオプションを提供します。デフォルトのスクワッシュメッセージはPRタイトル＋説明、PRタイトル＋コミットリスト、カスタムフォーマットから選択可能です。線形履歴を要求するブランチ保護ルールを設定することで、メインブランチのクリーンな状態を維持できます。

インタラクティブリベース

マージ前にインタラクティブリベースを使用すると、より細かい制御が可能です：

git rebase -i HEAD~5

共有ブランチにプッシュする前にリベースし、リモートの共有ブランチにあるコミットは決してリベースしないことが鉄則です。

コミットメッセージ規約

Conventional Commits形式が広く採用されています：

feat(api): ユーザー認証エンドポイントを追加

OAuth 2.0認証をリフレッシュトークン対応で実装。
- メール/パスワード検証によるログインエンドポイント
- JWTトークンの生成と検証
- セキュリティ向上のためのリフレッシュトークンローテーション

Closes #123

Squash mergeでは最終的なコミットメッセージが特に重要です。個々のコミットメッセージは1つに統合されるため、PRの説明に全文脈を記述することが不可欠です。

チームワークフロー統合

Squash mergeの成功にはチーム全体の合意と以下の取り組みが必要です：

1. ブランチ戦略の定義（Git Flow、GitHub Flow、trunk-based）
2. マージポリシーの設定（リポジトリ設定）
3. コミット規約の文書化
4. CIによる自動施行
5. チームのトレーニング

典型的なGitHub Flowでは、フィーチャーブランチを作成し、開発者がリベースでWIP履歴を整理し、PRをsquash mergeしてメインブランチを常に線形でアトミックな状態に保ちます。

よくある落とし穴

Squashによる個々のコミット詳細の喪失を防ぐには、PR説明に全文脈を記載します。無関係な変更を1つのコミットにまとめる乱暴なsquashing、コンフリクト解決後のsquashによるコンテキスト喪失、無関係な変更を含んだ誤プッシュなどに注意が必要です。

結論

Squash MergeはクリーンなGit履歴を維持するための強力なツールですが、意図的なワークフロー戦略の一部として最も効果的です。チームはいつsquashし、いつ通常マージし、どの情報をコミットメッセージに残すべきかを話し合い、合意する必要があります。適切な戦略はチームサイズ、リリースサイクル、デバッグと監査に必要な詳細レベルに依存します。