git 在合并分支时有两种策略，是 Fast-forward 和 recursive。
合并分支时有如下两种情况。
Situation One
现在在 master 分支上有两次提交。基于 c2 的提交创建了分支 feature，在分支 feature 上做了两次提交。如下图。
此时如果将 feature 合并到 master 时就会如下图。
执行的步骤是：
在 master 分支上执行 git merge feature
上面的情况的合并策略是 Fast-foward。
如果在 master 分支上执行 git merge --no-ff feature 那么将会保留分支的信息。结果如下图
即使删除了 feature 分支，分支提交信息也会保留。上面合并策略是 recursive。
Situation Two
现在在 master 分支上有两次提交。基于 c2 的提交创建了分支 feature，然后在 feature 做了两次提交，但是在将 feature 合并到 master 之前，已经有人先一步修改了 master。如下图。
merge
如果将 feature 合并到 master 上时，采用如下命令：
在 master 分支上执行 git merge feature
那么合并后的结果就会如下图。
其中 m1 是在将 feature 合并到 master 输入的提交信息。上面的合并策略是 recursive。
如果在 master 分支上执行 git merge --squash feature，那么 feature 上面的提交都会被压缩在 m1 提交中，f1 和 f2 将看不到了。
在 master 分支上将只能看到 m1 的提交记录。
rebase
如果执行采用 rebase ，采用如下命令：
在 feature 分支上 git rebase master
然后切换到 master 分支上 git merge feature
这样合并后的得到的结果如下图。
执行 rebase 后 feature 分支变成这样了
然后将 feature 合并到 master 上
rebase 操作的特点，把分叉的提交历史整理成一条直线，但是本地的分叉提交已经内修改过了。
上面情况的合并策略是 Fast-forward 。
补充：
下面这种情况，你的开发历史从一个更早的地方开始分叉开来 diverged。因为 master 分支所在提交并不是 iss53 分支所在提交的直接祖先，git 不得不做一些额外的工作。出现这种情况的时候，git 会使用两个分支的末端所指的快照 c4 和 c5，以及这两个分支的工作祖先 c2，做一个简单的三方合并。
git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。这个被称作一次合并提交，它的特别之处在于他有不止一个父提交。
git 会自行决定选择哪一个提交作为最优的共同祖先，并以此作为合并的基础。
参考文档：
https://www.liaoxuefeng.com/wiki/896043488029600/1216289527823648