一、前言

• 了解了管理或者維護 Git 倉庫、實現代碼控制所需的大多數日常命令和工作流程，嘗試跟了蹤和提交文件的基本操作，并且掌握了暫存區和輕量級地分支及合并的威力。如果想進一步對 Git 深入學習，可以學習一些 Git 更加強大的功能，這些功能可能并不會在日常操作中使用，但在某些時候可能還是會起到一定的關鍵性作用。
• 如果還不清楚 Git 的基礎使用流程、分支的管理、托管服務器的技術以及分布式工作流程等相關的技術和能力，請參考博客：
• • Git之深入解析Git的安裝流程與初次運行Git前的環境配置；
• • Git之深入解析本地倉庫的基本操作·倉庫的獲取更新和提交歷史的查看撤銷以及標簽別名的使用；
• • Git之深入解析Git的殺手級特性·分支管理與變基的開發工作流以及遠程分支的跟蹤；
• • Git之深入解析如何運行自己的Git倉庫托管服務器；
• • Git之深入解析如何使用Git的分布式工作流程與如何管理多人開發貢獻的項目。
• 除了主要作為版本控制工具外，Git 也提供了幾個命令來輔助我們調試項目源碼中的問題。由于 Git 被設計成適用于幾乎所有類型的內容，這些工具也相當通用，但它們往往可以在出現問題時幫助我們找到 bug 或者原因。

二、文件標注

• 如果在追蹤代碼中的一個 bug，并且想知道是什么時候以及為何會引入，文件標注通常是最好用的工具，它能顯示任何文件中每行最后一次修改的提交記錄。所以，如果在代碼中看到一個有 bug 的方法，可以使用 git blame 標注這個文件，查看哪一次提交引入了這行。
• 如下所示，用 git blame 確定了 Linux 內核源碼頂層的 Makefile 中每一行分別來自哪個提交和提交者，此外用 -L 選項還可以將標注的輸出限制為該文件中的第 69 行到第 82 行：

$ git blame -L 69,82 Makefile b8b0618cf6fab (Cheng Renquan 2019-05-26 16:03:07 +0800 69) ifeq ("$(origin V)", "command line") b8b0618cf6fab (Cheng Renquan 2019-05-26 16:03:07 +0800 70) KBUILD_VERBOSE = $(V) ^1da177e4c3f4 (Linus Torvalds 2020-04-16 15:20:36 -0700 71) endif ^1da177e4c3f4 (Linus Torvalds 2020-04-16 15:20:36 -0700 72) ifndef KBUILD_VERBOSE ^1da177e4c3f4 (Linus Torvalds 2020-04-16 15:20:36 -0700 73) KBUILD_VERBOSE = 0 ^1da177e4c3f4 (Linus Torvalds 2020-04-16 15:20:36 -0700 74) endif ^1da177e4c3f4 (Linus Torvalds 2020-04-16 15:20:36 -0700 75) 066b7ed955808 (Michal Marek 2020-07-04 14:29:30 +0200 76) ifeq ($(KBUILD_VERBOSE),1) 066b7ed955808 (Michal Marek 2020-07-04 14:29:30 +0200 77) quiet = 066b7ed955808 (Michal Marek 2020-07-04 14:29:30 +0200 78) Q = 066b7ed955808 (Michal Marek 2020-07-04 14:29:30 +0200 79) else 066b7ed955808 (Michal Marek 2020-07-04 14:29:30 +0200 80) quiet=quiet_ 066b7ed955808 (Michal Marek 2020-07-04 14:29:30 +0200 81) Q = @ 066b7ed955808 (Michal Marek 2020-07-04 14:29:30 +0200 82) endif

• 請注意，第一個字段是最后一次修改該行的提交的部分 SHA-1 值。接下來兩個字段的值是從提交中提取出來的，作者的名字以及提交的時間，所以就可以很輕易地知道是誰在什么時候修改了那一行。然后就是行號和文件內容，注意一下 ^1da177e4c3f4 這個提交的幾行，其中的前綴 ^ 指出了該文件自第一次提交后從未修改的那些行。這會帶來小小的困惑，因為目前至少已經看到三種 Git 使用 ^ 來修飾一個提交的 SHA-1 值的不同含義，但這里確實就是這個意思。
• 另一件比較酷的事情是 Git 不會顯式地記錄文件的重命名，它會記錄快照，然后在事后嘗試計算出重命名的動作，這其中有一個很有意思的特性就是可以讓 Git 找出所有的代碼移動，如果在 git blame 后面加上一個 -C，Git 會分析正在標注的文件，并且嘗試找出文件中從別的地方復制過來的代碼片段的原始出處。比如，將 GITServerHandler.m 這個文件拆分為數個文件，其中一個文件是 GITPackUpload.m，對 GITPackUpload.m 執行帶 -C 參數的 blame 命令，就可以看到代碼塊的原始出處：

$ git blame -C -L 141,153 GITPackUpload.m f344f58d GITServerHandler.m (Scott 2019-01-04 141) f344f58d GITServerHandler.m (Scott 2019-01-04 142) - (void) gatherObjectShasFromC f344f58d GITServerHandler.m (Scott 2019-01-04 143) { 70befddd GITServerHandler.m (Scott 2019-03-22 144) //NSLog(@"GATHER COMMI ad11ac80 GITPackUpload.m (Scott 2019-03-24 145) ad11ac80 GITPackUpload.m (Scott 2019-03-24 146) NSString *parentSha; ad11ac80 GITPackUpload.m (Scott 2019-03-24 147) GITCommit *commit = [g ad11ac80 GITPackUpload.m (Scott 2019-03-24 148) ad11ac80 GITPackUpload.m (Scott 2019-03-24 149) //NSLog(@"GATHER COMMI ad11ac80 GITPackUpload.m (Scott 2019-03-24 150) 56ef2caf GITServerHandler.m (Scott 2019-01-05 151) if(commit) { 56ef2caf GITServerHandler.m (Scott 2019-01-05 152) [refDict setOb 56ef2caf GITServerHandler.m (Scott 2019-01-05 153)

• 這個功能很有用，通常來說，我們會認為復制代碼過來的那個提交是最原始的提交，因為那是第一次在這個文件中修改了這幾行。但 Git 會告訴我們第一次寫這幾行代碼的那個提交才是原始提交，即使這是在另外一個文件里寫的。

三、二分查找

• 當知道問題是在哪里引入的情況下文件標注可以查找問題，如果不知道哪里出了問題，并且自從上次可以正常運行到現在已經有數十個或者上百個提交，這個時候就可以使用 git bisect 來幫助查找。bisect 命令會對你的提交歷史進行二分查找來幫助我們盡快找到是哪一個提交引入了問題。
• 假設剛剛在線上環境部署了我們的代碼，接著收到一些 bug 反饋，但這些 bug 在之前的開發環境里沒有出現過，這就百思不得其解，我們重新查看了代碼，發現這個問題是可以被重現的，但是不知道哪里出了問題。我們可以用“二分法”來找到這個問題。
• 首先執行 git bisect start 來啟動，接著執行 git bisect bad 來告訴系統當前所在的提交是有問題的，然后必須使用 git bisect good <good_commit>，告訴 bisect 已知的最后一次正常狀態是哪次提交：

$ git bisect start $ git bisect bad $ git bisect good v1.0 Bisecting: 6 revisions left to test after this [ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo

• Git 發現在標記為正常的提交（v1.0）和當前的錯誤版本之間有大約 12 次提交，于是 Git 檢出中間的那個提交。 現在可以執行測試，看看在這個提交下問題是不是還是存在，如果還存在，說明問題是在這個提交之前引入的；如果問題不存在，說明問題是在這個提交之后引入的。假設測試結果是沒有問題的，可以通過 git bisect good 來告訴 Git，然后繼續尋找：

$ git bisect good Bisecting: 3 revisions left to test after this [b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing

• 現在在另一個提交上了，這個提交是剛剛那個測試通過的提交和有問題的提交的中點，我們再一次執行測試，發現這個提交下是有問題的，因此可以通過 git bisect bad 告訴 Git：

$ git bisect bad Bisecting: 1 revisions left to test after this [f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table

• 這個提交是正常的，現在 Git 擁有的信息已經可以確定引入問題的位置在哪里，它會告訴我們第一個錯誤提交的 SHA-1 值并顯示一些提交說明，以及哪些文件在那次提交里被修改過，這樣就可以找出引入 bug 的根源：

$ git bisect good b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04 Author: PJ Hyett <pjhyett@example.com> Date: Tue Jan 27 14:48:32 2009 -0800secure this thing:040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730 f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config

• 當完成這些操作之后，我們應該執行 git bisect reset 重置你的 HEAD 指針到最開始的位置，否則會停留在一個奇怪的狀態：

$ git bisect reset

• 這是一個可以幫助我們在幾分鐘內從數百個提交中找到 bug 的強大工具。事實上，如果有一個腳本在項目是正常的情況下返回 0，在不正常的情況下返回非 0，可以使 git bisect 自動化這些操作。首先，設定好項目正常以及不正常所在提交的二分查找范圍，可以通過 bisect start 命令的參數來設定這兩個提交，第一個參數是項目不正常的提交，第二個參數是項目正常的提交：

$ git bisect start HEAD v1.0 $ git bisect run test-error.sh

• Git 會自動在每個被檢出的提交里執行 test-error.sh，直到找到項目第一個不正常的提交，也可以執行 make 或者 make tests 或者其他東西來進行自動化測試。

總結

以上是生活随笔為你收集整理的Git之深入解析如何使用Git调试项目源码中的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。