孤魂野鬼
原始版本如下：

            o - A   <-- name1
          /
o - o - o - o - B   <-- name2
      \       /
        o - C       <-- name3

现在把name1移动到B：

            o - A
          /
o - o - o - o - B   <-- name1, name2
      \       /
        o - C       <-- name3

当没有名字指向A的时候，A以及A前面那个提交就成为了孤魂，也就有可能被gc掉。我们可以通过reflog来恢复他，但git只会为我们保存30天。

现在，把name3也移动到B：

            o - A
          /
o - o - o - o - B   <-- name1, name2, name3
      \       /
        o - C

但是C这个时候并不是孤魂野鬼，它可以通过name3^1来访问。因故他是合法的。所以branch才会在合并之后才能被合法删掉。

把name1移动到B就不是一次fast-forward，把name3移动到B就是。
可以理解为顺着已有的（合并）线移动。
概念：当且仅当一个name移动后，还能碰到之前指向的点的时候，成为一次fast-forward操作。

fast-forward合并是非常流畅的。假使你进行一次fast-forward push，那么git做的事情就是把你本地的repo复制到中心repo，然后顺着fast-forward的路把master指向你的master，不会出现任何孤魂。

merge的时候使用fast-forward与否的区别

若加上--no-ff选项，则会不使用fast-forward进行合并。这个时候feature分支上的更改会做作为一个新的提交，回到master上。
而如果使用--ff选项，若master上没有别人的新提交，那么原本指向master最新的head会直接移动到feature的最新上。

为什么公共分支上使用rebase之后不给push？

如上文所说，push到中心repo之后，中心只接受fast-forward得来的结果。再引用之前的一个例子
[站外图片上传中...(image-209ec8-1516171303565)]
中心repo发现从旧的feature移动到新的feature，那么旧的D将会成为一个孤魂，所以被服务器拒绝了。
当A使用--force来强行推送之后，其实B的D开头的feature还是合法的，最后会被git变得尽量fast-forward，也就是会把中心repo上的feature所代表的分支上面的所有内容D'作为一个陌生的新提交和E进行合并。