導入
開発プロジェクトが進行するにつれ、Gitのコミット履歴が「WIP（作業中）」や「タイポ修正」といった細かなコミットで溢れかえり、いざ障害調査や機能の変更履歴を追おうとすると、目的の箇所を見つけるのに苦労した経験はないでしょうか。本稿では、メインブランチの可読性を劇的に向上させる「Squash and Merge」と「Rebase and Merge」の仕組みと、現場での適切な使い分けについて解説します。
基礎知識
Gitの共同開発において、プルリクエスト（PR）をマージする際、デフォルトでは「Merge Commit（マージコミット）」が作成されます。これは全ての履歴を保持しますが、多人数で頻繁にマージを行うと履歴が複雑に絡み合い、いわゆる「スパゲッティ状態」になります。これを回避するために用いられるのが以下の手法です。
Squash and Merge: PR内の全てのコミットを1つにまとめ、メインブランチに新しいコミットとして追加します。履歴が簡潔になり、機能単位での管理が容易になります。
Rebase and Merge: PRのコミット履歴をメインブランチの先端にそのまま繋ぎ直します。マージコミットを作らず、一直線の美しい履歴を維持できます。
実装/解決策
現場での運用ルールとして、以下の基準を推奨します。
1. 小規模な修正や単一機能の実装: 「Squash and Merge」を選択します。履歴の細部よりも「この機能がいつ入ったか」という単位を重視する場合に有効です。
2. 長期的な開発タスクや、複数の開発者が関わるPR: 「Rebase and Merge」を選択します。個別のコミットが持つ意味（リファクタリング、ロジック修正など）を維持しつつ、直線的な履歴を保つことができます。
GitHub/GitLabの設定で、プロジェクトのポリシーとしてこれらを強制することが可能です。開発チームの運用ルールに合わせて、不要なマージ戦略をオフにしておきましょう。
サンプルプログラム
ローカル環境で「Rebase」の挙動をシミュレートするコマンド例です。チームのメインブランチ（main）に変更を取り込む際の手順を示します。
1. 最新のmainブランチをプル
git checkout main
git pull origin main
2. 自分の作業ブランチに切り替え
git checkout feature/add-login-api
3. mainブランチの最新状況をベースに自分のコミットを積み直す（Rebase）
これにより、mainの最新コミットの直後に自分の作業が繋がります
git rebase main
4. コンフリクトが発生した場合は修正後、以下を実行
git add .
git rebase –continue
5. 強制プッシュ（Rebaseにより履歴が書き換わるため）
git push origin feature/add-login-api –force-with-lease
応用・注意点
現場で最も注意すべき点は、Rebaseは履歴を書き換える行為であるという点です。公開済みのブランチに対して不用意に実行すると、他のメンバーの作業と競合し、混乱を招きます。
回避策として「–force-with-lease」の使用を徹底しましょう。単なる「–force」は他人のプッシュを上書きしてしまうリスクがありますが、「–force-with-lease」はリモート側の状況を確認し、予期せぬ上書きを防ぐ安全装置として機能します。また、Squashを行う際は、コミットメッセージにPRの番号や、なぜその変更が必要だったかのコンテキストをしっかり記載する運用を徹底してください。履歴を綺麗にする目的は「後から追跡しやすくするため」であることを忘れないようにしましょう。
コメント