如果你是個經(jīng)常用git blame找“兇手”的開發(fā)者那你一定經(jīng)歷過這種絕望你盯著一行“屎山”代碼鼠標(biāo)懸停在 gutter行號側(cè)邊欄的 blame 信息上看到一個熟悉的名字和幾個月前的提交哈希。你心想“就是這貨這行就是他寫的看他怎么解釋”結(jié)果點進(jìn)去一看那哥們只是好心修復(fù)了一個拼寫錯誤真正引入這坨邏輯的“元兇”藏在他之前的某個提交里。普通的git blame只能告訴你“這行最后被誰改了”但改的人可能只是路過順手做了一次格式化。你想找到最初引入問題的作者就不得不手動執(zhí)行g(shù)it log -p在提交歷史里像偵探一樣順藤摸瓜狼狽不堪。Zed 最新 版本終于把這件糟心事給解決了——Zed 現(xiàn)在支持在 Blame 信息里直接追溯到父提交Parent Revisions了。? 新特性把“賴賬”的路堵死更新之后你再把鼠標(biāo)懸停在 gutter 的 blame 信息上時會發(fā)現(xiàn)彈出的工具條多了一個 “Blame Previous Revision” 的選項?；蛘咧苯邮褂妹蠲姘逦业牟僮鞑襟E如下第一步先blame然后使用blame revision使用previous revision查看上一個提交也可以右擊某個提交選擇previous revision它的邏輯簡單粗暴但極其有效當(dāng)你在某一行代碼上執(zhí)行這個操作時Zed 會直接打開git blame的上一個版本即該行代碼變更前的父提交然后定位到同一行告訴你“在這一次改動之前這行是誰寫的提交信息是什么”。你可以一直點一直點一路追溯到該文件最初被創(chuàng)建的那個提交。配合在 gutter 中高亮顯示當(dāng)前正在追溯的提交整個過程非常直觀。這下好了真正寫“爛代碼”的人再也藏不住了。你可以在代碼審查時優(yōu)雅地點下“追溯父版本”然后截圖發(fā)給真正的作者“看這一行源頭是你三年前寫的當(dāng)時的上下文是啥” 不止是“找人背鍋”那么簡單往深了說這個功能的意義遠(yuǎn)不止于“找出最初的作者”。當(dāng)你面對一段超過兩年沒人動過的復(fù)雜邏輯或者是在調(diào)試一個上古時期遺留下來的 BUG 時能夠瞬間跳轉(zhuǎn)并查看它在歷史各次提交中的變化直接就把你的調(diào)試體驗從“黑盒猜謎”升級成了“有據(jù)可查的考古發(fā)掘”。配合之前版本加入的editor::BlameRevision和新增的editor::BlamePreviousRevision操作你甚至可以把這兩個動作綁定成快捷鍵。指尖一動就能在代碼的時光機(jī)里自由穿梭。 總結(jié)對“代碼考古”的終極致敬Zed 這次更新表面上是給 Git Blame 加了個回溯功能本質(zhì)上是在把 Git 強大的歷史追溯能力用最直觀的方式融合進(jìn)了編輯器的工作流里。它不再讓你滿足于知道“最后是誰動了這一行”而是鼓勵你去理解“這一行到底是怎么一步步變成今天這樣的”。在團(tuán)隊協(xié)作和代碼審查中這能幫你清晰地識別出真正需要為某段復(fù)雜邏輯負(fù)責(zé)的人進(jìn)行更精準(zhǔn)的溝通。對于那些需要經(jīng)常梳理遺留系統(tǒng)、或者單純想找到“萬惡之源”的開發(fā)者來說這個功能簡直稱得上“代碼神器”。就沖這“刨祖墳”的能力也值得你更新一下 Zed。