rebaseとmergeの違いは何ですか？

Question

Accepted Answer

**merge**と**rebase**はどちらも1つのブランチから別のブランチへ変更を統合しますが、方法が異なります。mergeは**履歴を保持**してマージコミットを作成し、rebaseは**履歴を書き直して**線形のシーケンスを作成します。それぞれの違いと使い分けを理解することが重要です。

## Merge — 履歴を保持する（統合する）

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — 線形の履歴のために書き直す（再生する）

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebaseはブランチのコミットを別のブランチの先端から開始するように**移動**させ、新しいコミットを作成します。これにより、きれいな線形の履歴が生成されます。

## Rebaseの黄金律

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## 各々をいつ使うか

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## なぜ重要なのか

rebaseとmergeの違いを理解することは重要です。どちらも変更を統合しますが、履歴に根本的に異なる影響をもたらすため、正しく（そして安全に）選択することが重要です。これはGitの実用的な知識であり、よく議論されるテーマです。

コアとなる区別は——**mergeは履歴を保持**（統合されたブランチを記録するマージコミットを作成し、真の開発の履歴を保持）し、**rebaseは履歴を書き直す**（コミットを別のブランチの先端に再生して、最新コードで作業されたかのようなきれいな線形シーケンスを作成）——プロジェクト履歴がどのように見えるか、どのように読めるかに影響します。

トレードオフを理解する（merge：正確だが潜在的にマージコミットで散らかっている、rebase：きれいで線形だがコミットを書き直す）ことは、真の履歴を重視するか線形性を重視するかに基づいて選択するのに役立ちます。

最も重要なのは、**rebaseの黄金律**を理解することです——**プッシュ/共有されたコミットは絶対にrebaseしない**——これは必須です。なぜなら、rebaseはコミットを書き直す（新しいハッシュを与える）ため、共有された履歴をrebaseするとコラボレーターが持っているものから発散し、深刻な混乱と競合を引き起こすからです。rebaseは安全なのはローカルな、プッシュされていないコミットのみです。

この安全ルールは重要であり、違反されたときの一般的な問題の原因です。

**各々をいつ使うか**を理解する（共有ブランチを統合し履歴を保持する場合はmerge。これはしばしば、プルリクエストを通じた機能をマージする場合のチームデフォルト、ローカルコミットのクリーンアップ前に共有するまたは機能ブランチを線形に最新に保つ場合はrebase——ローカルコミットのみ）はGitの適切な実践を反映しています。

変更を統合することは基本的であり、merge対rebaseの選択（その履歴と安全性への影響を伴う）は頻繁な決定であり、インタビューのトピックです。したがって、その違い——履歴への影響、重要な黄金律、各々をいつ使うか——を理解することは、実用的で重要なGitの知識であり、きれいな履歴を安全に保つ中心であり、すべての開発者が把握すべき一般的に議論される区別です。