最終更新:
Git mergeとrebaseの違いは？履歴・競合・使い分けを図解
ひよこ mergeとrebaseは何が違うの？
ペンギン先生 どちらも別のブランチの変更を取り込む方法だけれど、履歴の扱いが違うよ。mergeは既存の履歴をつなぎ、rebaseは対象コミットの変更を別の土台へ順に適用し直すんだ。
ひよこ mergeすると必ずマージコミットができる？
ペンギン先生 必ずではないよ。現在の先端が取り込む先の祖先なら、ポインターを進めるfast-forwardが可能。この場合は新しいマージコミットを作らない。分岐した履歴を通常のmergeで合流させると、複数の親を持つコミットができるんだ。
ひよこ rebaseすると全部のハッシュが変わる？
ペンギン先生 ひよこ pushした後は絶対に使えないの？
ペンギン先生 共有相手がその履歴を基に作業しているなら、無断で作り直さないのが基本だよ。チームで合意した個人用ブランチなどでは扱うこともあるけれど、初心者は未共有の作業で練習しよう。force pushを通常の解決策にはしないことだね。
ひよこ mainの変更を作業ブランチへ入れるなら？
ペンギン先生 作業ブランチにいることと、未コミット変更がないことを確認するよ。履歴を維持するならmerge、未共有のコミットを新しい土台に整理するならrebaseが候補。まずmainがどの状態を指しているかも確認しよう。
ひよこ 競合の直し方は違うの？
ペンギン先生 どちらも競合した内容を確認して修正し、解決したファイルをgit addする。mergeは統合時にまとめて競合する一方、rebaseは適用するコミットごとに止まることがあるよ。続行と中止のコマンドも操作ごとに違うんだ。
ひよこ 途中で分からなくなったら？
ペンギン先生 まずgit statusで現在の状態を確認しよう。処理中ならgit merge --abortやgit rebase --abortで中止できる。操作前に未コミット変更を整理しておくことが大事で、完了後にいつでもabortできるわけではないよ。
ひよこ 一直線なら品質も高いのかな？
ペンギン先生 履歴の形だけでは決まらないよ。マージの経緯を残したいか、まとまった変更単位を見たいかはチームの方針次第。統合後はテストと差分確認を行い、競合を消しただけで正しいと判断しないようにしよう。
3つの履歴を区別する
| 操作・状態 | 新しいコミット | 主な用途・注意 |
|---|---|---|
| fast-forward merge | 作らず先端を進める | 取り込む履歴が現在の先端から続いている場合 |
| 分岐した履歴の通常merge | マージコミットを作る | 分岐・合流の経緯を保持 |
| rebase | 適用し直すコミットを新規作成 | 共有相手の作業への影響を確認 |
自分の未共有ブランチで試す手順
前提はmainとfeatureが存在し、作業ツリーがクリーンで、ローカルのmainが取り込みたい状態であることです。次の2方式は、どちらか一方を選ぶ例です。
git status
git switch feature
git merge main未共有コミットを載せ替える場合は、最後をgit rebase mainにします。リモートの最新状態は自動では取得されません。必要なら事前にfetchし、チームの方針に従って取り込む参照を選びます。
競合時に使うコマンド
| 状態 | 修正してgit addした後 | 処理中に中止する |
|---|---|---|
| merge中 | git merge —continue | git merge —abort |
| rebase中 | git rebase —continue | git rebase —abort |
rebase --skipは変更を飛ばす操作なので、「競合を直すのが面倒だから」で使わないでください。rerereで過去の解決を再利用する場合も、再適用された差分の確認は必要です。
参考資料
確認日：2026年9月26日。製品の仕様・料金・対応環境は導入時にも確認してください。
- Git: git-merge：fast-forward、マージコミット、continue/abort、未コミット変更の注意。
- Git: git-rebase：変更の再適用、continue/abort/skip、共有履歴への影響。