程序人生 | 谁动了我的代码？

已经夜里十一点了，周锦峰仍端坐在办公桌前，盯着屏幕上的代码死命地挠头。

明天就要上线了，代码却依然没有完全通过。周锦峰很疑惑，明明上周五刚刚做了集中测试，当时全都没问题的，按理说这周代码的改动也不多啊，团队就六七个人，大家提交代码之前都互相审阅，怎么就报错了呢？更让他想不通的是，屏幕上这个错误他隐约记得几个月前出现过，当时查了好多资料，最后用了一种很取巧的方法解决了，怎么今天又出现了呢？不幸的是，他在写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