图解 Git 基本命令 merge 和 rebase

关注

原创最新推荐文章于 2026-04-08 10:33:43 发布 2.4k 阅读 AI 写同款· GEO 优化 ›

OpenClaw Mac本地部署保姆级教程：手把手教你“养龙虾” 聊天：直接与AI助理对话问你好后，AI回复下图内容：可以命令OpenClaw自动完成改名操作。管理技能：安装/卸载各种功能扩展查看日志：实时监控运行状态配置定时任务：让龙虾自动干活恭喜！现在你的Mac上已经有了一只功能强大的“小龙虾”。你可以通过Web界面或终端与它对话，让它帮你处理邮件、管理日程、编写代码，甚至控制智能家居。把它当实习生：初期多检查它的工作成果给最小权限：只授予完成任务所需权限定期审计：查看行为日志，发现异常及时处理及时更新保持最新版本。阅读详情

green-leaf-merge-git

Git 基本命令 merge 和 rebase，你真的了解吗？

前言

Git 中的分支合并是一个常见的使用场景。

仓库的 bugfix 分支修复完 bug 之后，要回合到主干分支，这时候两个分支需要合并；
远端仓库的分支 A 有其他小伙伴合入了代码，这时候，你需要和远端仓库的分支 A 进行合并；

以上只是列举了分支合并的一些常见场景，关于 merge 和 rebase 命令你足够了解吗？

HEAD 的理解

在介绍本文的主要内容之前，我们先理解一下 HEAD 。

HEAD 指向当前所在的分支，类似一个活动的指针，表示一个「引用」。例如当前在 develop 分支，HEAD 内容就是 ref: refs/heads/develop。

HEAD 既可以指向「当前分支」的最新 commit，也可以指向历史中的某一次 commit (「分离头指针」的情况)。归根结底，HEAD 指向的就是某个提交点。

当我们做分支切换时，HEAD 会跟着切换到对应分支。

fast-forward 与 --no-ff 的区别

假如有一个场景：有两个分支，master 分支和 feature 分支。现在，feautre 分支需要合并回 master 分支。

fast-forward-初始状态

fast-forward 合并方式是条件允许的情况，通过将 master 分支的 HEAD 位置移动到 feature 分支的最新提交点上，这样就实现了快速合并。这种情况，是不会新生成 commit 的。

fast-forward

--no-ff 的方式进行合并，master 分支就会新生成一次提交记录。

--no-ff

如果条件满足时，merge 默认采用的 fast-forward 方式进行合并，除非你显示的加上 --no-ff 选项；而条件不满足时，merge 也是无法使用 fast-forward 合并成功的！

merge 操作

上面用图解的方式介绍了 fast-forward 和 --no-ff 的区别。下面，结合实际的代码仓进行合并操作，举几个栗子理解一下。

git merge 操作是区分上下文的。当前分支始终是目标分支，其他一个或多个分支始终合并到当前分支。这个注意点记住了，方便记忆！所以，当需要将某个分支合并到目标分支时，需要先切到目标分支上。

fast-forward 合并

刚刚一直在强调条件允许的时候，fast-forward 才能合并成功。条件指的是什么呢？

其实指的是源分支和目标分支之间没有分叉（单词 diverge），这种情况才可以进行快速合并。如果是下图中的场景，无法通过 HEAD 的快速移动实现分支的合并！

下面进行一个不分叉的场景的示例：

featuren 分支的初始状态

现在需要将 feature 分支合入到 master 分支，默认使用 fast-forward 方式：

# 切到目标分支
git checkout master
git merge feature

命令行里显示了 Fast-forward 的提示：

合入效果

看一眼 master 分支合入的前后对比（注意 HEAD 的位置）：

master 分支合入前

master 分支合入后

no-ff 合并

不分叉的场景是否可以强制采用 --no-ff 方式合并呢？可以！

# master 回到合入前的状态
git reset --hard d2fa1ae
git merge feature --no-ff

no-ff

这次命令行没有 Fast-forward 的提示了。

看一眼 master 分支图：

no-ff

这个图和上面讲解 no-ff 命令时的示意图一致，果然会有新 commit 生成。

分叉场景的合并

上面的图展示了我们经常遇到的一个场景，特性分支创建之后，源分支也会有新的提交。这就是形成分叉了。

这时候如果我们进行合并呢？

git merge feautre

分支图

可以看到，虽然默认会尝试 fast-forward 的方式进行合并，但是因为分叉了，所以此时会采用 no-ff 的方式进行合并！有新的 commit 生成了！

fast-forward 方式对应的合并参数是 --ff

我们试试这个参数 --ff-only，顾名思义，就是强制只使用 ff 方式进行合并：

# 回到合并前
git reset --hard 3793081
git merge feature --ff-only

合并终止

经过测试，当分叉时，因为无法使用 ff 方式合并，即使你强制指定使用该方式合并也不行，会提示终止！

附上 Git 官方文档中的解释，方便理解：

With --ff, when possible resolve the merge as a fast-forward (only update the branch pointer to match the merged branch; do not create a merge commit). When not possible (when the merged-in history is not a descendant of the current history), create a merge commit.

rebase 操作

rebase 命令是一个经常听到，但是大多数人掌握又不太好的一个命令。rebase 合并往往又被称为「变基」，我称为「基化」🤣。「基」的理解很重要，理解了它，其实 rebase 命令你就掌握了。

我的描述可能并不准确，只是为了能够帮助你理解。这里的「基」就是一个「基点」、「起点」的意思。「变基」就是改变当前分支的起点。注意，是当前分支！ rebase 命令后面紧接着的就是「基分支」。

变基前：

git reabse master feature 变基后：

变基后

git rebase 命令通常称为向前移植（forward porting）。

变基提交示例

我们接下来进行实际的测试，将代码库状态构造成分叉的状态，状态图如下：

分叉初始状态

以 master 分支为基，对 feautre 分支进行变基：

git checout feature
git rebase master

以上两行命令，其实可以简写为：git rebase master feature

特性分支 feature 向前移植到了 master 分支。经常使用 git rebase 操作把本地开发分支移植到远端的 origin/<branch> 追踪分支上。也就是经常说的，「把你的补丁变基到 xxx 分支的头」

变基后

可以发现，在 master 分支的最新节点（576cb7b）后面多了 2 个提交（生成了新的提交记录，仅仅提交信息保持一致），而这两个提交内容就是来自变基前 feature 分支，feature 分支的提交历史发生了改变。

观察上图还可以发现，变基后，改变的只是 feature 分支，基分支（master 分支）的 HEAD 指针依然在之前的 commit （576cb7b）处。这时候要将 feature 分支合入到 master 分支上，就满足 fast-forward 的条件了，master 分支执行快速合并，将 HEAD 指针指向刚刚最新合入的提交点：

git checkout master
git merge feature

快速合并

看下图 master 分支图，观察 HEAD 指针的位置：

rebase 变基操作最适合的是本地分支和远端对应跟踪分支之间的合并。这样理解可能会更清晰一点。比如，远端仓库里有一个特性分支 feature，除了你开发之外，还有其他人往这个分支进行合入。当你每次准备提交到远端之前，其实可以尝试变基，这时候基分支就是远端的追踪分支。

下图是仓库的分支图：

与远端分支分叉

git fetch
git rebase origin/feature feature

变基后

观察上图，我们本地的提交以远端分支的最新提交为「基」，将差异提交重新进行了提交！远端分支的提交记录依然是一条直线~如果分叉的情况，不采用这种「变基操作」，而直接采用 merge 的方式合并，就会有如下这种分支提交图：

no-ff 合并

因为分叉了，采用 git pull 时也没法 fast-forward 合并，只能采用 no-ff 方式合并，最后的提交历史就会像上图那样。会产生一个合并提交。同时，分支图也显得稍微杂乱了一点，因为 feature 分支不是一条直线了。但是，其实也有好处，可以实际的看出来合并的提交历史。该选择哪个，往往取决于团队的选择策略。