Gitのrerere(reuse recorded resolution)は、マージやリベースの際に発生したコンフリクト(競合)の解決方法をGit自身に記憶させ、同じコンフリクトが将来再び発生したときに自動で再適用させるための強力な機能である。特に長期にわたるブランチ開発や、頻繁なリベースを行うワークフローで、手作業によるコンフリクト解決の繰り返しを防ぎ、作業効率を大幅に向上させる。
1. rerereの基本と有効化
A. rerereの仕組み
- 衝突の記録(Preimage): コンフリクトが発生すると、Gitは衝突前のファイルの状態を
.git/rr-cache/
ディレクトリにハッシュ値で記録する(これをPreimageと呼ぶ)。 - 解決の記録(Postimage): ユーザーがコンフリクトを手動で解決し、
git add
してからgit commit
(またはgit rebase --continue
など)を行うと、Gitはその解決後の状態を記録する(Postimage)。 - 解決の再利用: 次回、同じPreimageを持つコンフリクトに遭遇した場合、Gitは記録されたPostimageを自動的に適用する。
B. 有効化の方法(必須)
rerereはデフォルトでは無効になっているため、以下のコマンドで有効にする必要がある。
スコープ | コマンド |
---|---|
グローバル(すべてのリポジトリ) | git config --global rerere.enabled true |
ローカル(現在のリポジトリのみ) | git config rerere.enabled true |
2. rerereの応用テクニックと活用シーン
A. 長期ブランチの頻繁な同期
長期フィーチャーブランチ(開発に時間がかかるブランチ)をmain
やdevelop
ブランチに追従させるために、定期的にリベースやマージを行う場合、同じコンフリクトが何度も発生しがちである。
活用方法: 一度目のリベース/マージでコンフリクトを解決すれば、二度目以降の追従作業ではrerereが自動で解決を適用してくれる。
git checkout feature-branch
# 初回:ここでコンフリクトを解決・コミットし、rerereに記憶させる
git rebase main
# 2回目以降:自動解決される
git rebase main
B. 「テストマージ」とマージコミットの破棄
フィーチャーブランチがmain
と結合した状態で正しく動作するか確認するために一時的なマージを行い、履歴をクリーンに保つためにそのマージコミットを破棄するワークフロー(“Test Merge”)がある。
- テストマージを実行し、コンフリクトを解決・コミットする。(rerereが解決を記録)
- テストを実行し、問題ないことを確認する。
- マージコミットを破棄する。
git reset --hard HEAD^
最終的な正式マージ(またはリベース)を行う際、rerereが以前の解決を再適用するため、手動での再解決が不要になる。
3. rerere利用時のヒントと注意点
A. 自動解決後の確認を怠らない
rerereがコンフリクトを自動で解決した後でも、そのファイルはステージングされた状態で停止する。これは、Gitがユーザーに最終確認を促しているためである。
必須の操作: rerereが自動解決を行った際は、必ず以下の手順を踏むこと。
git status
やgit diff
で自動解決の内容を確認する。- 単体テストや統合テストを実行し、解決後のコードが意図通りに動作することを確認する。
- 問題なければ、
git commit
またはgit rebase --continue
などで作業を完了する。
B. 誤った解決の削除
もし、過去に誤った解決方法をrerereに記録させてしまった場合、次回同じコンフリクトに遭遇したときに間違った解決が自動で適用されてしまう。その場合は、forget
サブコマンドを使って記録を削除し、手動で正しい解決をやり直すこと。
特定のファイルの記録を削除:
# 現在のコンフリクト中のファイル(例: src/file.js)の記録を削除
git rerere forget src/file.js
C. 状態確認用のサブコマンド
rerereは通常、自動で動作するが、以下のコマンドで現在の動作状況を確認できる。
git rerere status
: 現在のコンフリクト処理において、rerereが関与しているファイルを表示する。git rerere diff
: rerereが現在適用しようとしている(または適用した)解決策の差分を表示し、手動での確認を助ける。