概要
Git では、履歴をリニアに保つために merge と並び、rebase もよく利用されます。
本稿では、rebase の基本的な考え方から、コンフリクト解消の具体的手順、そして解消後の push 時の注意点について、初心者でも理解しやすいように丁寧に解説します。
1. 背景と rebase の基本概念
1.1 なぜ rebase を使うのか？
複数人で同じリポジトリを運用している場合、他のメンバーによって main ブランチがどんどん進んでいく中、古いブランチで作業しているとその変更との差分が大きくなる場合があります。
このとき git rebase を使うことで、自分の作業ブランチを最新の main の先端に「付け替え」ることができ、履歴をリニアに保ちながら統合しやすくなります。
# 例：feature ブランチを最新の main に基づかせる
git checkout feature
git rebase main
1.2 rebase が行う処理
-
ブランチの移動: 現在のブランチ（例：feature）のコミットを一時的に退避し、最新の main の先頭に置き換えた後、退避した変更を1つずつ再適用していきます。
-
履歴の整理: これにより、マージコミットが不要となり、コミット履歴が一列に並び見通しがよくなります。
2. rebase 中に発生するコンフリクトの検出
2.1 コンフリクトの検出
リベース中、以下のようなメッセージが表示されることがあります。
CONFLICT (content): Merge conflict in <ファイル名>
これは、他のブランチで修正された内容と、自分の変更部分が同じ箇所にあった場合に発生します。
3. コンフリクト解消の具体的手順
ここでは、リベース中に起こったコンフリクト解消の流れを、具体例とともに解説します。
ステップ 1: コンフリクト状態の確認
まず、どのファイルにコンフリクトが発生しているかを確認します。
git status
出力例:
You are currently rebasing branch 'feature' on 'main'.
Unmerged paths:
both modified: src/app.js
ステップ 2: コンフリクト箇所の特定と修正
コンフリクトが発生しているファイルをエディタで開くと、以下のようにコンフリクトの区切りが表示されます。
<<<<<<< HEAD
現在取り込もうとしている内容（main 側の変更）
=======
自分が加えた変更内容（feature 側の変更）
>>>>>>> <コミットID>
選択肢:
-
自分の変更を優先する: 自分の変更内容のみを残し、不要なマーカーを削除します。
-
取り込み先 (main) の変更を優先する: main 側の内容をそのまま採用する場合は、feature の変更部分とマーカーを削除します。
-
両方を統合する: 場合によっては、両側の内容を統合して、より良い形で修正することも可能です。
ステップ 3: 解消済みファイルのステージング
修正が完了したら、対象ファイルをステージに追加します。
git add <修正したファイル>
ここで git commit は不要です。
ステップ 4: rebase の再開
すべてのコンフリクトが解消できたら、rebase を再開します。
git rebase --continue
Git は次のコミットに対して再び適用を試み、もしさらにコンフリクトが発生した場合は同様の手順を繰り返します。
ステップ 5: rebase の中止（必要な場合）
もし解消が複雑になった場合は、以下のコマンドで作業前の状態に戻すことが可能です。
git rebase --abort
4. rebase 後の push に関する注意点
リベース後、リモートブランチに push するときには注意が必要です。
すでにリモートに同じブランチが存在する場合、通常の push では下記のようなエラーが出ることがあります。
! [rejected] feature -> feature (non-fast-forward)
これは、ローカルの履歴がリモートと一致しないため発生します。
リベースによって履歴が書き換えられているため、強制的に push する必要があります。
git push --force origin HEAD
※ 強制 push はリモートの履歴を書き換える操作のため、チーム内でのルールやコミュニケーションを十分に取った上で実施してください。
6. まとめ
-
rebase の目的:
履歴をリニアに整理し、見通しの良いブランチ運用を実現するための強力なツール。 -
コンフリクト解消:
コンフリクト発生時はエディタで差分部分を確認し、適切な内容に修正 → git add してから git rebase --continue を実行。 -
push 時の注意:
リベース後の履歴変更はリモート側と乖離するため、強制 push (git push --force) が必要。
これらの手順を理解し、実際に運用することで、より快適な Git ワークフローが実現できるでしょう。
なお、各社・チームごとのポリシーに沿った運用や、詳細な設定については、最新のドキュメント等も参考にしてください。