誰動了我的程式碼？
圖片來源網路
已經夜裡十一點了，周錦峰仍端坐在辦公桌前，盯著螢幕上的程式碼死命地撓頭。
明天就要上線了，程式碼卻依然沒有完全通過。周錦峰很疑惑，明明上週五剛剛做了集中測試，當時全都沒問題的，按理說這周代碼的改動也不多啊，團隊就六七個人，大家提交程式碼之前都互相審閱，怎麼就報錯了呢？更讓他想不通的是，螢幕上這個錯誤他隱約記得幾個月前出現過，當時查了好多資料，最後用了一種很取巧的方法解決了，怎麼今天又出現了呢？不幸的是，他在寫 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 <[email protected]> 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