git rebaseの使い方
mergeとの違いと履歴を整える実践テクニック

どちらも「あるブランチの変更を別の状態と合流させる」操作ですが、 履歴の残り方 が決定的に違います。次の状況を例にします。main が先に進んでいて、自分のfeature ブランチを最新のmain に合わせたい場面です。

merge は分岐と合流の事実をそのまま記録します。rebase はfeature のコミットを いったん外して main の最新コミットの上に並べ直す イメージです。このとき F1・F2 は内容こそ同じでも 別のコミットとして作り直され、ハッシュが変わります （図でF1' と表記しているのはこのためです）。これが後述の黄金ルールに直結する、最重要ポイントです。

長く作業しているとmain が先に進み、自分のブランチが古くなります。これを最新化するのが一番基本的な rebase です。feature ブランチにいる状態で実行します。 Step 1

# まず main の最新を取得しておく
$ git switch main
$ git pull origin main

# 作業ブランチに戻り、main の上に rebase する
$ git switch feature
$ git rebase main
#Successfully rebased and updated refs/heads/feature.

これでfeature は「最新の main から枝分かれしたかのような」きれいな状態になります。merge で追従するとマージコミットが積み重なって履歴が複雑になりがちですが、rebase なら一直線を保てます。

作業中はfix: typo 、wip 、やっぱり戻す のような細かいコミットが増えがちです。これらを公開前に 意味のある単位へまとめ直す のが対話的 rebase（git rebase -i ）です。

$ git rebase -i HEAD~3

エディタが開き、対象コミットが「やることリスト（todo）」として並びます。各行の先頭のpick を、別のアクションに書き換えて操作します。

pick a1b2c3d feat: ログイン機能を追加
pick d4e5f6g fix: typo修正
pick h7i8j9k fix: もう一つのtypo

下の2つを最初のコミットにまとめたい場合、pick をsquash （またはfixup ）に変えます。

pick a1b2c3d feat: ログイン機能を追加
squash d4e5f6g fix: typo修正
fixup h7i8j9k fix: もう一つのtypo
# squash = 直前のコミットに統合し、メッセージは編集する
# fixup  = 直前のコミットに統合し、メッセージは捨てる

保存してエディタを閉じると、3つのコミットが1つのfeat: ログイン機能を追加 にまとまります。todo で使える主なアクションは次の通りです。

rebase はコミットを作り直す＝ 履歴を書き換える 操作です。すでにpush して他人が取得しているコミットを rebase すると、自分の手元と共有先で「同じはずのコミット」が食い違い、チーム全体が混乱します。

では「自分の作業ブランチを整理した後、すでに push 済みだった」場合はどうするか。履歴が変わっているため通常の push は拒否されます。このときだけ--force-with-lease を使います。

# 通常の push は拒否される
$ git push origin feature
#! [rejected]  feature -> feature (non-fast-forward)

# --force-with-lease なら「他人の新しい変更がない」ことを確認した上で上書きする
$ git push origin feature --force-with-lease

rebase はコミットを1つずつ順番に適用し直すため、途中でコンフリクト（競合）が起きると、その地点で停止します。慌てず次の3コマンドで対応します。

# 競合発生。どのファイルが衝突したか確認
$ git status

# ① ファイルを編集して競合を解消したら、解決済みとして add
$ git add 解決したファイル

# ② 次のコミットへ処理を進める
$ git rebase --continue

# やり直したくなったら、rebase前の状態に完全に戻す
$ git rebase --abort