如何用Git工具發(fā)現(xiàn)和解決開發(fā)項(xiàng)目中的痛點(diǎn)
在日常開發(fā)和項(xiàng)目管理過程中往往不可避免地存在很多痛點(diǎn)。如果能及時(shí)發(fā)現(xiàn)和解決掉這些問題，可以極大提高開發(fā)我們的開發(fā)效率和減輕項(xiàng)目的技術(shù)債務(wù)，減少項(xiàng)目風(fēng)險(xiǎn)。很多減輕技術(shù)債務(wù)的工具都是預(yù)防性的。比如編譯器，lint，靜態(tài)分析工具等。這些工具都通過防止開發(fā)人員簽入代碼碼，這一方面限制了開發(fā)人員的自由，引起不適，而且可能會(huì)導(dǎo)致一些潛在的問題。而且盡管通過管制和審核流程似乎應(yīng)該是完美無瑕的代碼，但是實(shí)際上并不一定會(huì)帶來功能良好的系統(tǒng)。
軟件開發(fā)的過程不僅涉及開發(fā)人員之間以及開發(fā)人員與他人團(tuán)隊(duì)之間的交互，如何快速的無聲的項(xiàng)目的痛點(diǎn)這是個(gè)問題。如果你的開發(fā)項(xiàng)目是采用git管理，那么Git本身就能給我們很多好用的工具，本文蟲蟲就給大家講講git中自帶哪些解決痛點(diǎn)的工具。
git log 發(fā)現(xiàn)最常改變?yōu)槲募?/strong>
我們時(shí)常忽略一個(gè)事實(shí)是，我們經(jīng)常修改的，修改最多的文往往是問題發(fā)生最多的，而這些文件往往就是開發(fā)和項(xiàng)目的痛點(diǎn)。我們要找到這些痛點(diǎn)，或者熟悉一個(gè)未知的項(xiàng)目不知道如何入手的時(shí)候，首先可以做的就是找出項(xiàng)目中改變最多，提交commit最頻繁的文件。找出倉庫最常變化的文件(top10)命令為：
- git log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -rg | head -10
比如我們最開源安全項(xiàng)目OpenSSH查看一下top10變化文件：
我們可以看到除了，版本更新文檔ChangeLog以外，變化第二的是configure.ac這個(gè)文件是項(xiàng)目編譯文件makefile的配置文件。源碼里面修改最多的是sshd.c是sshd服務(wù)器端的源代碼文件。
可以看到這個(gè)命令很有用，但是很長不好記，怎么辦?其實(shí)也好辦，那就是加一個(gè)git別名即可。vim打開~/.gitconfig配置文件，在[Aliases]部分增加以下配置項(xiàng)：
- cctop10 = "!git log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -rg | head -10"
這樣，對一個(gè)倉庫我們只需執(zhí)行這樣做是按照更改的數(shù)量對項(xiàng)目中的文件進(jìn)行排序，并獲取前10個(gè)文件。隨著時(shí)間的推移，這些文件中發(fā)生的更改最多，因此，這些文件中需要更改的機(jī)會(huì)更大。
git blame 找出痛點(diǎn)的來源
在知道變化最多的文件這個(gè)痛點(diǎn)后，我們需要詳細(xì)了解痛點(diǎn)過程?；蛘唔?xiàng)目的另一個(gè)痛點(diǎn)是，發(fā)現(xiàn)項(xiàng)目文件被某人修改后就崩潰了，再也跑不起來了。想找出是誰修改的，大家來鄙視他，或者譴責(zé)(blame)它。這就需要一個(gè)git另一個(gè)利器blame，他就是告訴我們這個(gè)問題行(變化)是誰引入的。比如我們同樣以openssh 項(xiàng)目為例，查看一下sshd.c的文件的變化歷史
git blame sshd.c:
如上我們可以看到基本上每一行代碼出現(xiàn)的現(xiàn)場，包括了commitID、提交人、詳細(xì)時(shí)間和代碼。
如果文件較大，可以通過"-L"參數(shù)指定開始和結(jié)束行，比如sshd.c文件的200行開始的20行內(nèi)容的來源。
關(guān)于git blame 注意：
如果一個(gè)commitID前面有^號，那么自文件創(chuàng)建以來，對應(yīng)的行就從沒修改過。
blame也可以跟蹤跨文件的行變化。比如對一個(gè)大文件代碼重構(gòu)或者配置文件被分散到多個(gè)小文件，那么會(huì)顯示大文件中的原始提交和大文件的名稱?？赏ㄟ^-C選項(xiàng)來實(shí)現(xiàn)。
git bisect 找到引入問題的commit
如果知道是哪個(gè)行代碼，那次commit引入的問題，我們可以用blame揪出提交問題的人。但是如果不知道是哪兒引入的問題，需要找出引入問題的提交。則需要用一個(gè)git 工具bisect。它也很簡單用二分發(fā)不斷測試回溯到中間的commit點(diǎn)，直到找到這個(gè)問題引入點(diǎn)。
git bisect start [終點(diǎn)] [起點(diǎn)]
終點(diǎn)為你確保有問題的commit(如果不能確定那就是現(xiàn)在HEAD)，起點(diǎn)為你確保的之后才出現(xiàn)的問題(如果不確定就用最開始一次commits)。
執(zhí)行這個(gè)命令后，項(xiàng)目倉庫的文件狀態(tài)會(huì)調(diào)到這兩次的中間commit，這時(shí)候測試代碼，如果項(xiàng)目運(yùn)行OK，就執(zhí)行g(shù)it bisect good。如果還是報(bào)錯(cuò)，則執(zhí)行g(shù)it bisect bad。
執(zhí)行后，git會(huì)根據(jù)good或者bad狀態(tài)跳轉(zhuǎn)到后半段commit的一半(即3/4)commit處，或者1/4 commit處
繼續(xù)測試代碼，標(biāo)識(shí)good或者bad
以此類推直到找到引入問題commit。
總結(jié)：
git是一個(gè)天生為開發(fā)而生的工具，生來就是為了幫助我們解決痛點(diǎn)的。而且git中很多工具就是對應(yīng)解決我們?nèi)粘＞唧w痛點(diǎn)的，善用他們不光可以讓我日常生活更舒服，也能極大提高開發(fā)效率。"工欲善其事，必先利其器"，"磨刀不誤砍柴工"希望我們會(huì)用并且善用這些工具。
