作者：张东宇 时间: 2020/7/9
如果你只对不会离开你电脑的提交执行变基，那就不会有事情。
你开始工作的起点，克隆下面的仓库。
远程仓库的初始状态
克隆到本地之后，你进行了一些修改创建了C3 和 C4。
创建C3 和 C4
现在你对代码满意准备合并后提交，同时，你想让你的远程仓库代码保持一条直线，看起来更美观。
其实我心目中给变基操作有一个更接地气的翻译，嫁接：把某些分支的一部分或全部嫁接到另外一条分支上。达到精简分支结构，或是保留有用的代码，移除无效代码的目的。
把exeriment分支的C4 变基到master 分支上
如果只是对像这样完完全全的本地生长出来的分支进行变基合并，不会翻车。
如果你对已经推送至共用仓库的提交上执行变基命令，并因此丢失了一些别人开发所基于的提交，那你就有大麻烦了，你的同事也会因此鄙视你
愉快的一天开始了，我是你的同事，你同我一起开始工作，一起克隆代码。
初始的远程仓库
现在是下午三点了，你了看看本地代码。
你的代码
又看了看远程代码仓库，发现张某某已经提交了一些代码。
远程仓库
嗯哼，此时此刻你决定先合并张某某的代码， 你git pull，然后又进入到了愉快的工作之中...
现在一切还正常
到了三点半张某某粗来搞事情了，他感觉自己上次提交没有用变基心里不爽,使用变基合并之后强制推送到了远程仓库。
此时远程仓库发生了改变，而你的代码的一部分是基于改变前的远程仓库的。
此时远程仓库发生了改变
现在是下午四点半了，你准备再pull一次后push代码下班班。
image.png
此时此刻你发现多出来一个C4‘，而且C4' 又和C7 做了一次合并，出现了C8...
如果此时此刻你直接向远程仓库推，远程仓库就会变成和你这样一样乱七八糟。此时此刻，你想的第一件事肯定是鄙视张某某。
如果你对已经推送过的提交执行变基，但别人没有基于它的提交，那么也不会有事。
emmm 这句话我纠结了很久，其实是个非常简单的情况
如果陈某某在张某某第二次push之后合并代码,就躲过了一劫。
张某某把旧的代码结构改变了，破坏了采用先前代码结构的开发者代码结构的完整，如果你合并了他旧的代码结构，就会无辜中枪，如果你合并的是最新的代码结构，对你没什么影响。
