Git 中的 Rebase 与 Merge：原理、区别与最佳实践

文章目录

• • [1. 引言：为什么 Git 会有 rebase 和 merge 两种方式？](#1. 引言：为什么 Git 会有 rebase 和 merge 两种方式？)
  • [2. Git Merge：保留真实历史的合并](#2. Git Merge：保留真实历史的合并)
  • • [2.1 Merge 的基本思想](#2.1 Merge 的基本思想)
    • [2.2 Merge 的使用方式](#2.2 Merge 的使用方式)
    • [2.3 Merge 的优点](#2.3 Merge 的优点)
    • [2.4 Merge 的缺点](#2.4 Merge 的缺点)
  • [3. Git Rebase：重写历史的"整理术"](#3. Git Rebase：重写历史的“整理术”)
  • • [3.1 Rebase 的基本思想](#3.1 Rebase 的基本思想)
    • [3.2 Rebase 的使用方式](#3.2 Rebase 的使用方式)
    • [3.3 Rebase 的优点](#3.3 Rebase 的优点)
    • [3.4 Rebase 的缺点](#3.4 Rebase 的缺点)
  • [4. Rebase 与 Merge 的核心区别](#4. Rebase 与 Merge 的核心区别)
  • • 操作位置对比
  • [5. 冲突处理上的区别](#5. 冲突处理上的区别)
  • • [Merge 冲突](#Merge 冲突)
    • [Rebase 冲突](#Rebase 冲突)
  • [6. 一个重要原则](#6. 一个重要原则)
  • [7. 实战推荐用法](#7. 实战推荐用法)
  • • [场景 1：个人功能分支](#场景 1：个人功能分支)
    • [场景 2：合并到主分支](#场景 2：合并到主分支)
    • [场景 3：提交前整理 commit](#场景 3：提交前整理 commit)
  • [8. GitHub / GitLab 的最佳实践](#8. GitHub / GitLab 的最佳实践)
  • 参考

1. 引言：为什么 Git 会有 rebase 和 merge 两种方式？

在团队开发中，我们经常会遇到这样的场景：

• 多个人在同一个仓库并行开发
• 主分支（main / master）在不断前进
• 自己的功能分支需要同步最新代码

这时，Git 给我们提供了两种选择：

• git merge
• git rebase

它们都能"合并代码"，那到底有什么区别？

---

2. Git Merge：保留真实历史的合并

2.1 Merge 的基本思想

merge 的核心思想是：

把两个分支的历史"汇合"在一起，并生成一个新的合并提交。

示意图如下：

A---B---C---D (main)
     \     /
      E---F (feature)

合并后：

A---B---C---D------M (main)
     \           /
      E---F----- (feature)

其中 M 是一个 Merge Commit。

---

2.2 Merge 的使用方式

git checkout main
git merge feature

注意要合并的时候切换到目标分支

---

2.3 Merge 的优点

• 不修改历史，绝对安全
• 提交记录完整可追溯
• 适合多人协作、公共分支

---

2.4 Merge 的缺点

• 提交历史可能出现大量 merge commit
• 日志图可能较为"杂乱"
• 不利于线性回溯提交

---

3. Git Rebase：重写历史的"整理术"

3.1 Rebase 的基本思想

rebase 的核心思想是：

把当前分支的提交"挪到"另一个分支的最新提交之后。

示意图：

A---B---C---D (main)
     \
      E---F (feature)

Rebase 后：

A---B---C---D---E'---F' (feature)

注意：

• E'、F' 是 新提交
• 原来的 E、F 已被替换

---

3.2 Rebase 的使用方式

git checkout feature
git rebase main

---

3.3 Rebase 的优点

• 提交历史 线性、干净
• 更容易阅读和回滚
• 非常适合整理本地提交

---

3.4 Rebase 的缺点

• 会 重写提交历史
• 如果操作不当，容易引发协作问题
• 不适合已经推送到远程的公共分支

---

4. Rebase 与 Merge 的核心区别

维度	merge	rebase
是否生成新提交	是（merge commit）	否（重写提交）
历史是否线性	否	是
是否修改历史	否	是
风险程度	低	高
适用场景	公共分支	本地分支

操作位置对比

操作	当前所在分支	目标分支	命令格式
git rebase	✓ 当前分支	要变基到的分支	git rebase 目标分支
git merge	✓ 当前分支	要合并进来的分支	git merge 来源分支

---

5. 冲突处理上的区别

Merge 冲突

• 只解决一次冲突
• 生成一个 merge commit

Rebase 冲突

• 每一个提交都可能冲突
• 需要多次 git rebase --continue

---

6. 一个重要原则

❗ 永远不要 rebase 已经推送到远程的公共分支

原因：

• 会改变提交 hash
• 导致他人无法正常拉取代码
• 可能引发灾难性冲突

---

7. 实战推荐用法

场景 1：个人功能分支

✅ 推荐 rebase

git checkout feature
git rebase main

目的：

👉 保持提交历史干净

---

场景 2：合并到主分支

✅ 推荐 merge

git checkout main
git merge feature

目的：

👉 保留真实开发历史

---

场景 3：提交前整理 commit

git rebase -i HEAD~3

可用于：

• 合并提交
• 修改提交信息
• 删除无用提交

---

8. GitHub / GitLab 的最佳实践

• 功能开发：rebase 同步主分支
• 最终合并：merge 或 squash merge
• 禁止对 main/master 执行 rebase

---

参考

【五分钟学会git rebase和 git merge的区别】

Git：图解 merge 和 rebase 的区别