记一次代码合并错误

扯淡

LZ 2014年本科毕业,计算机科学与技术(软件工程方向)专业,毕业后在一个二三线城市(郑州)工作了两年多的时间,职位就是PHP研发。后来经不住诱惑,来到了首都,进入了一初创型科技公司,研发人员50人左右,主要做教学相关的产品,对外号称做SaaS服务的,省略五百字。。。

在一个夜黑风高的晚上,LZ 又像往常一样在加班上线,在经历了测试人员各种虐以后,终于把所有已知的 bug 都改完了,那种感觉就像。。。不会形容那种感觉,总之LTM爽了。接下来就是合并代码了,合并完打一个 tag 交给运维上线,LZ 就可以回家搂着媳妇儿睡觉了。顺便介绍下我们的团队研发流程,假如有一个接口项目A,在 gitlab 上托管着(后续有炸弹),包含 master、fangzhen、develop 三个主要分支和各个版本小分支。老大分配一个任务,LZ 基于 master 建个 v1.x.x 分支,当前的任务就在此分支上搞。搞完了之后,分别往 develop(可以忽略不计)、fangzhen 上合一下,基于 fangzhen 打一个送测tag:release_v1.x.x并发送邮件。仿真环境测试负责发布,他们拿到 tag 后直接在 jenkins 就发布了。

就是在可以忽略不计的操作上——往 develop 分支上合并的时候,LZ 发现了一个冲突。Easy ,对比了下冲突的代码,发现LZ 的代码是最新的,就随手在 gitlab 后台点击了 use ours,完事儿提交代码。OK ,事故已经悄然来临了。由于不太清楚 gitlab 后台是怎么处理冲突的,总之最后的结果就是develop上所有的代码都 merge into 到了 LZ 的 v1.x.x 分支上。然后 LZ 在不知情的情况下欢快的往 fangzhen、master 又合了一下,打个稳定包 stagle_v1.x.x 就发布了。R 了 狗,发完之后公司的项目登不上了,刚开始还以为是跑旧数据的脚本把服务器干瘫了,后来发现服务器毛事儿没有,LZ 仿佛感觉到了哪里不对,然后去 gitlab 后台查看了下提交、合并记录,发现了不知什么时候把 develop 分支合到了LZ 的分支上,从天而降的锅坐实了是 LZ 的。

RM,合错了就撤回,但是 LZ 对 git 的操作还没有到炉火纯青的那一步,只能找公司的大牛来帮忙了。大牛在 LZ 确认过最后一次正确提交的 commit_id 后就开始干了,三下五除二就搞定了,佩服佩服。

划重点

假设:

分支名称 最后一次正确提交ID 说明
master aaaaaaaa
fangzhe bbbbbbbb
develop cccccccc 罪魁祸首
v1.x.x dddddddd

处理步骤:

  1. git reset –hard dddddddd && git push –force
  2. git reset –hard bbbbbbbb && git push –force
  3. git reset –hard aaaaaaaa && git push –force
  4. 再分别把 v1.x.x 分别合到 fangzhen、master 上,其余正常操作就完事

感悟:

  1. 生产环境数据处理首要考虑数据量,内存溢出,处理数据进度
  2. git怎么提交、合并代码才能不出错
  3. git代码合并错误回滚的步骤、常用操作命令