rebaseとは？非エンジニア向けにわかりやすく解説

3秒でわかる

自分のコミットを別の枝の先端へ乗せ直すGitの操作。枝分かれを消して、履歴をあとから読みやすい一本の直線に整えられます。

30秒図解

rebaseはfeature/cartのコミットをorigin/mainの先端へ順番に作り直して履歴を直線化し、元とは別のハッシュにする — rebaseは履歴を引き直す操作です。コミットのハッシュが変わるため、共有済みのブランチでは慎重に使います。

もう少し詳しく

どういうものか

rebase は、自分のブランチで作ったコミットを一度取り外し、指定した別のコミットの上に順番に作り直す操作です。土台を差し替えるので rebase と呼ばれます。結果として枝分かれが消え、あたかも最新の main から作業を始めたかのような一直線の履歴になります。作り直しである以上、コミットのハッシュ値は元と別のものになります。

なぜ必要か

長く作業していると main が先に進み、履歴が枝分かれします。merge で合流させると、機能に関係ない合流コミットが増え、あとから git log を追うときに読みづらくなります。rebase なら合流点が残らず、変更が時系列に並びます。レビューの単位が読みやすくなるのが主な利点です。障害を追うときも、どの変更がいつ入ったのかを上から順に読むだけで追えます。

具体例

git switch feature/cart
git <a href="/glossary/fetch-api" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">fetch</a> origin
git rebase origin/main          # main の先端の上に自分のコミットを乗せ直す

# 衝突したら直してから続ける
git add app/cart.ts
git rebase --continue

# やり直したくなったら中断
git rebase --abort

# 直近3つのコミットを整理する
git rebase -i HEAD~3

つまずきやすいところ

最大の落とし穴は、すでに push 済みのブランチを rebase してしまうことです。ハッシュが変わるため、他の人が持っている履歴と食い違い、force push が必要になります。共有ブランチでこれをやると同僚の作業が消えかねません。rebase してよいのは、自分しか触っていないブランチだけと考えます。もうひとつ、衝突の解決が1コミットずつ繰り返される点です。10コミット積んでいれば同じ箇所で10回聞かれることがあり、その場合は素直に merge を選ぶ判断もあります。衝突を避けたい一心で git rebase --skip を押すのも危険で、そのコミットの変更がまるごと消えます。迷ったら git rebase --abort で元の状態へ戻し、落ち着いてからやり直すほうが確実です。

似た用語との違い

操作	履歴の形	元のコミット
merge	枝分かれと合流が残る	そのまま残る
rebase	一直線になる	作り直されて別物になる
cherry-pick	特定の1つだけを別の枝へ複製	元も残る

覚え方

merge は道を合流させる操作、rebase は自分の道ごと別の場所へ引き直す操作です。引き直す以上、他人が歩いている道でやってはいけません。

rebaseとは？