如何用Git工具發現和解決開發項目中的痛點

在日常開發和項目管理過程中往往不可避免地存在很多痛點。如果能及時發現和解決掉這些問題，可以極大提高開發我們的開發效率和減輕項目的技術債務，減少項目風險。很多減輕技術債務的工具都是預防性的。比如編譯器，lint，靜態分析工具等。這些工具都通過防止開發人員籤入代碼碼，這一方面限制了開發人員的自由，引起不適，而且可能會導致一些潛在的問題。而且儘管通過管制和審核流程似乎應該是完美無瑕的代碼，但是實際上並不一定會帶來功能良好的系統。

軟體開發的過程不僅涉及開發人員之間以及開發人員與他人團隊之間的交互，如何快速的無聲的項目的痛點這是個問題。如果你的開發項目是採用git管理，那麼Git本身就能給我們很多好用的工具，本文蟲蟲就給大家講講git中自帶哪些解決痛點的工具。

git log 發現最常改變為文件

我們時常忽略一個事實是，我們經常修改的，修改最多的文往往是問題發生最多的，而這些文件往往就是開發和項目的痛點。我們要找到這些痛點，或者熟悉一個未知的項目不知道如何入手的時候，首先可以做的就是找出項目中改變最多，提交commit最頻繁的文件。找出倉庫最常變化的文件(top10)命令為：

1. git log  

比如我們最開源安全項目OpenSSH查看一下top10變化文件：

我們可以看到除了，版本更新文檔ChangeLog以外，變化第二的是configure.ac這個文件是項目編譯文件makefile的配置文件。源碼裡面修改最多的是sshd.c是sshd伺服器端的原始碼文件。

可以看到這個命令很有用，但是很長不好記，怎麼辦?其實也好辦，那就是加一個git別名即可。vim打開~/.gitconfig配置文件，在[Aliases]部分增加以下配置項：

1. cctop10 = "!git log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -rg | head -10" 

這樣，對一個倉庫我們只需執行這樣做是按照更改的數量對項目中的文件進行排序，並獲取前10個文件。隨著時間的推移，這些文件中發生的更改最多，因此，這些文件中需要更改的機會更大。

git blame 找出痛點的來源

在知道變化最多的文件這個痛點後，我們需要詳細了解痛點過程。或者項目的另一個痛點是，發現項目文件被某人修改後就崩潰了，再也跑不起來了。想找出是誰修改的，大家來鄙視他，或者譴責(blame)它。這就需要一個git另一個利器blame，他就是告訴我們這個問題行(變化)是誰引入的。比如我們同樣以openssh 項目為例，查看一下sshd.c的文件的變化歷史

git blame sshd.c:

如上我們可以看到基本上每一行代碼出現的現場，包括了commitID、提交人、詳細時間和代碼。

如果文件較大，可以通過"-L"參數指定開始和結束行，比如sshd.c文件的200行開始的20行內容的來源。

關於git blame 注意：

如果一個commitID前面有^號，那麼自文件創建以來，對應的行就從沒修改過。

blame也可以跟蹤跨文件的行變化。比如對一個大文件代碼重構或者配置文件被分散到多個小文件，那麼會顯示大文件中的原始提交和大文件的名稱。可通過-C選項來實現。

git bisect 找到引入問題的commit

如果知道是哪個行代碼，那次commit引入的問題，我們可以用blame揪出提交問題的人。但是如果不知道是哪兒引入的問題，需要找出引入問題的提交。則需要用一個git 工具bisect。它也很簡單用二分發不斷測試回溯到中間的commit點，直到找到這個問題引入點。

git bisect start [終點] [起點]

終點為你確保有問題的commit(如果不能確定那就是現在HEAD)，起點為你確保的之後才出現的問題(如果不確定就用最開始一次commits)。

執行這個命令後，項目倉庫的文件狀態會調到這兩次的中間commit，這時候測試代碼，如果項目運行OK，就執行git bisect good。如果還是報錯，則執行git bisect bad。

執行後，git會根據good或者bad狀態跳轉到後半段commit的一半(即3/4)commit處，或者1/4 commit處

繼續測試代碼，標識good或者bad

以此類推直到找到引入問題commit。

總結：

git是一個天生為開發而生的工具，生來就是為了幫助我們解決痛點的。而且git中很多工具就是對應解決我們日常具體痛點的，善用他們不光可以讓我日常生活更舒服，也能極大提高開發效率。"工欲善其事，必先利其器"，"磨刀不誤砍柴工"希望我們會用並且善用這些工具。

【編輯推薦】

【責任編輯：

華軒

TEL：[phone]】

點讚 0