git merge(3个模式) 与 git rebase 图文详解区别

目录

• [1 git merge](#1 git merge)
• • [1.1 模式一：fast-forward(--ff)](#1.1 模式一：fast-forward(–ff))
  • [1.2 模式二：non-Fast-forward(--no-ff)](#1.2 模式二：non-Fast-forward(–no-ff))
  • [1.3 模式三：fast-forward only(--ff-only)](#1.3 模式三：fast-forward only(–ff-only))
• [2 git rebase](#2 git rebase)
• [3 区别](#3 区别)

1 git merge

git merge有好几种不同的模式

默认情况下你直接使用 git merge 命令，git 来判断使用哪种 merge 模式

1.1 模式一：fast-forward(--ff)

master 与 feature存在公共祖先的情况

开发者小王接到需求任务，从 master 分支中创建功能分支，git 指令如下：

git checkout -b feature556
Switched to a new branch 'feature556'

小王在 feature556 分支上完成的功能开发工作，然后产生1次 commit

功能完成后自然要上线，我们把代码合并，完成上线动作

git checkout master
git merge feautre556

Fast-forward 是指 Master 合并 Feature 时候发现 Master 当前节点一直和 Feature 的根节点相同，没有发生改变，那么 Master 快速移动头指针到 Feature 的位置，所以 Fast-forward 并不会发生真正的合并，只是通过移动指针造成合并的假象，这也体现 git 设计的巧妙之处。合并后的分支指针如下：

1.2 模式二：non-Fast-forward(--no-ff)

master与feature不存在公共祖先

刚说了会产生 Fast-forward 的情况，现在再说说什么情况会产生 non-Fast-forward，通常，当合并的分支跟 master 不存在共同祖先节点的时候，这时候在 merge 的时候 git 默认无法使用 Fast-forward 模式，

可以看到 master 分支已经比 feature556 快了1个版本，master 已经没办法通过移动头指针来完成 Fast-forward，所以在 master 合并 feature001 的时候就不得不做出真正的合并，真正的合并会让 git 多做很多工作，具体合并的动作如下：

• 找出 master 和 feature001 的公共祖先，节点 c1，c2, c3 三个节点的版本 （如果有冲突需要处理）
• 创建新的节点 c4，并且将三个版本的差异合并到 c4，并且创建 commit
• 将 master 和 HEAD 指针移动到 c7

补充⭐：大家在 git log 看到很多类似：Merge branch 'feature556' into master 的 commit 就是 non-Fast-forward 产生的。

执行完以上动作，最终分支流程图如下：

1.3 模式三：fast-forward only(--ff-only)

...

2 git rebase

我们在自己的分支feature上开发了一段时间了（此时feature的基底是a），准备从主干master上拉一下最新改动

此时我们切换到feature分支上，执行rebase命令，想要把master分支合并到feature分支

git checkout feature
git rebase master

下图为变基后的提交节点图

rebase，变基，可以直接理解为改变基底。

feature分支是基于master分支的B拉出来的分支，feature的基底是a。而master在a之后有新的提交，到了c，就相当于此时要用master上新的提交来作为feature分支的新基底。

实际操作为把feature的提交先暂存下来，然后删掉原来这些提交，再找到master的最新提交位置，把存下来的提交再接上去（接上去是逐个和新基底处理冲突的过程），如此feature分支的基底就相当于变成了c而不是原来的a了。

（注意，如果master上在a以后没有新提交，那么就还是用原来的a作为基，rebase操作相当于无效，此时和git merge就基本没区别了，差异只在于git merge会多一条记录Merge操作的提交记录）

3 区别

• rebase：变基，会有一个干净的分支，但是对于记录来源不够清晰
• merge：合并，git分支看起来比较混乱，但是清楚各个记录的来源与时间节点

建议都用 merge