需求来了,甲同学在主干上做了一次commit, 经过团队的code review,以及QA同学的测试,没有问题. 改动了三个文件ABC.等着上线了就.

然后PM同学觉得这个需求可能这次上不了,先hold但是以后可能会上. 甲同学于是checkout了一个分支出去,就叫feature吧. 对了,多人开发嘛不是这一次commit还在主干上呢得revert回来啊. 无论有没有其他同学拉取到这次commit,都应该做一次revert吧. 于是甲同学在主干上做了一次revert.

接着这次feature的需求加了一点点,好吧在feature上改改改. 最后feature这个branch的文件变成了A'B'CD. 也就是说最终变动了AB文件并且新增了一个D文件.C文件还是原来那个. 接着再次code review,QA同学测试通过.

PM同学通知还是上吧这次需求. 上呗,于是甲同学准备把feature分支合入主干. AB文件有冲突了啊,解决冲突呗还能怎么着,于是顺利完成本次需求. 等着上线发版.that's all.

写到这里,你有没有发现问题, 注意C文件,把feature合入主干的时候是没有冲突的, 对,C文件在feature分支上就没有改动过. C文件里的内容还是本次需求上的.没有任何问题.

但是当你合回主干的时候,C文件的改动就是全部没了.

因为主干上你revert的时间是在feature分支checkout出去之前的. 其实合回主干的时候,你甚至都看不到关于C文件的任何输出. 你看到的只有AB文件的冲突以及新增的一个D文件.

对于git来说,C文件就应该还是上一次需求的C文件. git认为C文件还是上一次需求的C文件.就该是这样.

that's all.

当时我手都抖了,一合一个准,C文件的变动就是没了.怀疑人生了都.

真实情况: C文件代表好几个文件. 甲同学一共三个人. 主干上的revert是一个同学做的, 接着checkout出一个新分支继续开发又是另一个同学. 我呢我在feature分支上改了大概10行代码.就是A'B'. 临上线了,这两个同学都不在,生病请假了. 嗯,最终把代码合入主干的人是我. 至于这次merge的评审是怎么过的, 我啊,怪我,我私自让一个小兄弟给我过的. 当时主要负责这次需求的人都不在,我也不能不合吧. 你感受一下吧.

至于后来怎么把那些变动找回来,cherry pick了解一下. 光荣属于绿哥,百度的程序员真的很牛逼.

写到这里,心有余悸, 我被吓坏了,我被吓坏了,我被吓坏了, 对,我就是这么菜.

RD,QA,PM谁都没有问题.只怪我自己git段位低啊.

如果你是我,这种case你有几成把握能cover住,或者规避掉. 如果有,请收下我的膝盖我佩服你的git段位. 如果没有,注意一下吧.毕竟也算不得什么极端case.

周一还要厚着脸皮让QA同学重新跑case, 据说checklist有200多个. 唉 好害羞. 对了,我不怎么想去大团队大App了, 一个工程分成两个团队12个人的我就已经受不了了.