文章目录
-
- [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 mergegit 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 main3.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