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