git rebase と cherry-pick で履歴を編集する

ここからは Git の パワーツール。コミット履歴を後から 編集する 技術です。慣れると非常に便利ですが、「公開済みのコミットを書き換えてはいけない」 という大原則だけは絶対に守ってください。

rebase って何？

merge が「枝を合流させる」操作だったのに対し、rebase は 「枝の根元を別の場所に付け替える」 操作です。

merge が 「歴史を残す」 のに対し、rebase は 「歴史をきれいに整える」。コミット C・D は新しいコミット C’・D’ として 作り直される のがポイント。

rebase してみる

feature ブランチで作業中、main が先に進んだ場合：

意味は 「自分（feature）のコミットを main の最新の上に積み直す」。コンフリクトしたら手で解決して git rebase --continue、やめたければ git rebase --abort。

なぜ rebase を使うのか

• 履歴が一直線になって読みやすい：git log --graph がスッキリ
• 「同期だけのマージコミット」が積まれない：feature 開発中に「main の最新を取り込みたい」と git merge main や git pull（マージ方式）を何度もやると、その都度 Merge branch ‘main’ into feature が積まれて履歴が膨らみます。git rebase main に置き換えれば、これが一切残らず履歴が直列のまま保てます
• チームによっては「最終 merge する前に rebase してから」が作法

ただし 後述の通り、共有済みのコミットには使ってはいけません。

interactive rebase：履歴を整える究極の道具

-i オプションで 対話的rebase を起動すると、各コミットを「順番入れ替え」「メッセージ修正」「複数を1つに統合（squash）」「捨てる（drop）」できます。

エディタが開いて、こんな画面が出ます：

pick を s や f に書き換えて保存すると、自動でコミットが統合されます。

よくある使い道

• 「タイポ修正」みたいな小さなコミットを直前に統合したい → f（fixup）
• コミットメッセージを後から直したい → r（reword）
• 間違って入れてしまったコミットを消したい → d（drop）

cherry-pick：1コミットだけ持ってくる

「あのブランチのあのコミットだけ、こっちに欲しい」というとき。

そのコミットの 変更内容だけを「コピー」して、現ブランチの先頭に新しいコミットとして積みます。

典型的な使いどころ

• バグ修正コミットを別ブランチにも適用したい：hotfix-1.0 で直したやつを main にも cherry-pick
• 試作で作ったコミットの一部だけ採用したい

大原則：公開済みのコミットを書き換えない

rebase / 履歴編集は コミットIDを書き換える 操作。一度 push したコミットを書き換えると、チームメンバーのローカルと食い違って 大事故 になります。

「mainブランチを rebase した」のは禁忌。featureブランチを rebase してから merge する、はOK（自分しか触ってないので）。

merge と rebase、どっちを選ぶ？

チームによって「merge派」「rebase派」がありますが、初心者のうちは 「自分のfeatureを最新のmainに追従させる時は rebase、main にfeatureを取り込む時は merge」 くらいの分担が安全です。

やってみよう ①：3つのコミットを rebase -i で1つに squash する

「ちまちまコミット → 最後にきれいにまとめる」という王道フローを再現します。

3つの「ちまちまコミット」が 1つの整ったコミット になりました。チームに見せる前にこうして履歴を整えるのが「rebase の作法」。

やってみよう ②：別ブランチから1コミットだけ cherry-pick

ブランチ全体をマージせず、特定の1コミットだけ 持ってこれます。バグ修正をリリース版にも適用したい時の定番。

このレッスンのまとめ