已经夜里十一点了,周锦峰仍端坐在办公桌前,盯着屏幕上的代码死命地挠头。
明天就要上线了,代码却依然没有完全通过。周锦峰很疑惑,明明上周五刚刚做了集中测试,当时全都没问题的,按理说这周代码的改动也不多啊,团队就六七个人,大家提交代码之前都互相审阅,怎么就报错了呢?更让他想不通的是,屏幕上这个错误他隐约记得几个月前出现过,当时查了好多资料,最后用了一种很取巧的方法解决了,怎么今天又出现了呢?不幸的是,他在写git commit message的时候很粗心,一般就一句话:fix bugs。虽然自己也知道这个习惯不太好,但他一直懒得去改。这下倒好,他只能把这周的几十个提交一个个看下来了。
“我先走了。” 周锦峰抬了抬头,看见老李正朝着自己这边挥手。 “你也早点回去休息吧。” 老李接着说道,然后就背着单肩包往外面走去。“好的,明天见!” 周锦峰回应道,这下偌大的办公室就剩他一个了。他起身耸耸肩,又继续埋到代码堆里。
又过了十五分钟,他还是没什么头绪,却听到肚子开始咕咕叫。这时他才想起来,傍晚那会儿一直忙着开会,晚饭都还没吃呢。他赶忙到茶水间找了点面包牛奶,狼吞虎咽起来。还顺带拿了几包零食回来,继续投入战斗。但看着满屏的代码,觉得这么瞎找也不是个事。该怎么办呢?他苦苦思索着,在位子边上来回踱步。突然他想到,现在既然已经知道报错代码在哪了,如果能知道这几行代码是在哪次提交中被修改的,不就能知道它们原来是什么了吗?之前咋没想到呢?一定是自己太饿了,他在心里嘀咕道。他记得之前有个同事提过git blame可以查看代码的最后一次修改,但还一直没试过。说着他快速打开浏览器,查了下git blame的用法,然后迅速切换到命令行,在项目目录下敲了一行命令:
$ git blame py/core.py
果然,屏幕上弹出了当前代码最后一次修改的详情,包括了commit号,作者和时间等。他瞬间变得兴奋起来,两个手指轻轻地滑动着,找到了报错的那行代码,一个熟悉的名字映入眼帘,这行代码在这周果然被人改动过。他深吸了一口气,继续查找那个commit对应的具体信息:
$ git show a3a9b05
commit a3a9b055627ba5683c7dafa856f81263f0d231e1
Merge: 923675d d520f7c
Author: xxx <xxx@qq.com>
Date: Mon Feb 25 09:49:48 2019 +0800
Merge branch 'refactor'
又是该死的refactor!他突然有点生气。明明代码都还没完全稳定,但组长却总是要安排一两个人做重构的工作,搞得三天两头出问题。但转念一想他又觉得不对,如果是合并代码的话他应该需要参与审阅的啊,为什么自己对这个commit完全没有印象,难道是当时没告知他吗?想到这他的气阀又升高了些。他迅速打开了gitlab找到了对应的Merge Request详情,果然是没有抄送他就直接合并了。他感觉自己快气炸了,说好的流程怎么总是不遵守呢!他有点想骂人,但理智告诉他现在要冷静,解决问题才是第一位的。于是他做了几个深呼吸,根据这个Merge Request 的详情,把错误的那块代码给恢复了。然后他重新运行测试用例,静静等待结果,同时握了握双手,心想应该是改这个地方没错吧。大概10分钟之后,出结果了,一排绿色的pass。他长吁了一口气,心想终于可以回家了,刚才的怒火也消减了许多,有什么帐明天再算吧,这会老子要睡觉了。他迅速地整理好代码,准备提交到gitlab上。在写提交信息的时候,他觉得还是有必要记录下这个该死的问题,于是慎重地敲了一行命令:
$ git commit -am 'fix bugs borrowed by xxx refactor branch!'
[fix_bug 11750f3] fix bugs borrowed by xxx refactor branch!
1 file changed, 10 insertion(+)
他看了眼屏幕,满意地点了点头。随即关闭电脑,起身离开公司。
充实的一天又结束了呢,他在心里默念到。
以上就是本文的全部内容,如果您喜欢这篇文章,欢迎将它分享给朋友们。
感谢您的阅读,祝您生活愉快!
作者:小美哥
2019-03-10
网友评论