rebase 和 merge 之间有什么区别？

Question

Accepted Answer

**merge** 和 **rebase** 都将来自一个分支的更改集成到另一个分支中，但它们的做法不同：merge **保留历史记录**，带有一个 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 **移动**你的分支提交以从另一个分支的顶端开始，创建新的提交——产生一个干净、线性的历史记录。

## Rebasing 的黄金规则

```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 保留历史记录**（创建一个 merge 提交来记录分支的合并，保留真实的开发历史记录）而 **rebase 重写历史记录**（将提交重放到另一个分支的顶端以创建一个干净、线性的序列，就像工作是在最新代码上完成的一样）——影响项目历史记录的外观和可读性。

理解权衡（merge：准确但可能因 merge 提交而混乱；rebase：干净且线性但重写提交）有助于根据是否看重真实历史还是线性整洁来选择。

最关键的是，理解 **rebasing 的黄金规则**——**永远不要 rebase 已被推送/共享的提交**——至关重要，因为 rebasing 重写提交（赋予它们新的哈希），所以对共享历史进行 rebase 会与协作者拥有的内容分歧，造成严重的混淆和冲突；rebase 只对本地的、未推送的提交是安全的。

这个安全规则至关重要，是违反时常见的问题来源。

理解**何时使用每一个**（merge 用于集成共享分支和保留历史记录，通常是通过拉取请求合并功能的团队默认做法；rebase 用于在共享前清理本地提交或保持特性分支线性最新——仅限本地提交）反映了正确的 Git 实践。

由于集成更改是基础性的，merge-vs-rebase 的选择（带有其历史记录和安全隐含）是频繁的决定和面试话题，理解差异——它们对历史记录的影响、关键的黄金规则以及何时使用每一个——是有价值的、实际重要的 Git 知识，对于安全地维护干净历史记录至关重要，也是每个开发人员都应该理解的常见讨论的区别。