Git 变基翻车实例

作者：张东宇 时间: 2020/7/9

---

如果你只对不会离开你电脑的提交执行变基，那就不会有事情。

你开始工作的起点，克隆下面的仓库。

远程仓库的初始状态

克隆到本地之后，你进行了一些修改创建了C3 和 C4。

创建C3 和 C4

现在你对代码满意准备合并后提交，同时，你想让你的远程仓库代码保持一条直线，看起来更美观。

其实我心目中给变基操作有一个更接地气的翻译，嫁接：把某些分支的一部分或全部嫁接到另外一条分支上。达到精简分支结构，或是保留有用的代码，移除无效代码的目的。

把exeriment分支的C4 变基到master 分支上

如果只是对像这样完完全全的本地生长出来的分支进行变基合并，不会翻车。

如果你对已经推送至共用仓库的提交上执行变基命令，并因此丢失了一些别人开发所基于的提交，那你就有大麻烦了，你的同事也会因此鄙视你

愉快的一天开始了，我是你的同事，你同我一起开始工作，一起克隆代码。

初始的远程仓库

现在是下午三点了，你了看看本地代码。

你的代码

又看了看远程代码仓库，发现张某某已经提交了一些代码。

远程仓库

嗯哼，此时此刻你决定先合并张某某的代码， 你git pull，然后又进入到了愉快的工作之中...

现在一切还正常

到了三点半张某某粗来搞事情了，他感觉自己上次提交没有用变基心里不爽,使用变基合并之后强制推送到了远程仓库。

此时远程仓库发生了改变，而你的代码的一部分是基于改变前的远程仓库的。

此时远程仓库发生了改变

现在是下午四点半了，你准备再pull一次后push代码下班班。

image.png

此时此刻你发现多出来一个C4‘，而且C4' 又和C7 做了一次合并，出现了C8...

如果此时此刻你直接向远程仓库推，远程仓库就会变成和你这样一样乱七八糟。此时此刻，你想的第一件事肯定是鄙视张某某。

如果你对已经推送过的提交执行变基，但别人没有基于它的提交，那么也不会有事。

emmm 这句话我纠结了很久，其实是个非常简单的情况

如果陈某某在张某某第二次push之后合并代码,就躲过了一劫。

张某某把旧的代码结构改变了，破坏了采用先前代码结构的开发者代码结构的完整，如果你合并了他旧的代码结构，就会无辜中枪，如果你合并的是最新的代码结构，对你没什么影响。

如果你的同事干了这种破事，你可以再执行一次变基...