rebase的实质

什么是fast-forwards?
看起来好像是把你的feature branch怼出来然后再重新怼到源分支的最新版本后面，那这是真的吗？
当然不是。查看log你会发现，虽然两者的log信息一摸一样，但是hash码变了！网上也说了，其实并不是怼出来怼回去那么简单，而是重建了一份提交！
git从来不丢失文件。在rebase之前，连接到源有节点的那些提交还是在的，如果你还记得他们的版本号，一样可以checkout出来，只不过，它已经不属于任何有效分支了。

黄金法则

1.png

2.png

这个时候b想把他rebase之后的结果推到线上。

push的实质
中央仓库拿到你的分支，即someone/master之类的，他要做的其实是merge客户端所要求的的分支。

当rebase之后，那条branch其实已经不是那条branch了（只是看起来像）。远端想把你的feature合并到远端的feature，但是不知道怎么合并（不知道要把这个新的提交接到老featrue的哪个地方啊）

3.png

这个时候Bob强行要推上去，加了个--force标志，结果把远端变成了他本地的样子。这个时候Anna改了东西，想推送到远端。前面说过，rebase之后其实是新建了一条分支，并删除了原来的分支。远端现在已经是没有这条分支了，这个时候Anna上传出错。

COUCIOUS
git不会丢失任何提交。上图中浅蓝色的提交代表着他并没有消失，还可以访问到。

4.png

然后Anna乖乖地做了一次pull。git把东西从远端拉下来，合并。喜闻乐见地，Anna发现自己的仓库里有两条一样的changeset。