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 的核心思想是：

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

示意图如下：

latex 复制代码

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

合并后：

latex 复制代码

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

其中 M 是一个 Merge Commit。

2.2 Merge 的使用方式

bash 复制代码

git checkout main
git merge feature

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

2.3 Merge 的优点

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

2.4 Merge 的缺点

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

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

3.1 Rebase 的基本思想

rebase 的核心思想是：

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

示意图：

latex 复制代码

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

Rebase 后：

latex 复制代码

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

注意：

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

3.2 Rebase 的使用方式

bash 复制代码

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

bash 复制代码

git checkout feature
git rebase main

目的：

👉 保持提交历史干净

场景 2：合并到主分支

✅ 推荐 merge

bash 复制代码

git checkout main
git merge feature

目的：

👉 保留真实开发历史

场景 3：提交前整理 commit

bash 复制代码

git rebase -i HEAD~3

可用于：

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

8. GitHub / GitLab 的最佳实践

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

参考

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

Git：图解 merge 和 rebase 的区别