倉庫大到 git status 要十幾秒：有人用 Rust 自製了一個 Git GUI

先看這則貼文裡最容易被略過的那一行：「執行一個 git status 就需要十幾秒」。這是開發者 cmzy 於 V2EX 發文時給出的起點。公司的 monorepo 越長越大，平常的 GUI 工具在這種規模下開始卡頓，於是他用 Rust 搭配 Zed 團隊開源的 gpui 框架，自己做了一個名為 GeeTree 的 Git 圖形用戶端，網站掛在 geetree.app。

大倉庫為什麼會拖垮工具

Git 在小倉庫裡的反應接近即時，但 monorepo 把大量目錄、分支與歷史塞進同一個工作區後，每次 status、diff 都要掃過整棵檔案樹。這就像住戶從三樓公寓換成整座社區，管家還是挨家挨戶按門鈴查戶口，自然越查越慢。

這也是命令列工具與 GUI 工具近年反覆被拿來比較的原因。原發文者表示沒有實測過 lazygit，但自稱比 Tower、GitKraken、Fork 都快，另外搜尋功能做了全文索引，反應也快。這些說法目前只有作者自述，尚無第三方測試佐證。

自製工具背後的訊號

這類貼文真正值得注意的，並非又多了一個 Git 用戶端，而是瓶頸確實存在。AI 輔助寫程式讓產出速度變快，code review 的量反而增加，原作者也提到「都需要 review 啊」。當審查變成日常瓶頸，工具速度就成了直接的工作體感。

用 gpui 做桌面工具也是值得留意的一步。這套框架因 Zed 編輯器而生，標榜高頻渲染下的效能，近年逐漸被拿來寫其他需要快速反應的桌面應用。若這類案例增多，Rust 加 gpui 可能成為「受不了既有工具的人」的另一條路。

這與先前開發者不滿 Fences 收費而自製 PecoFence 的模式相同：付費牆或效能牆出現時，總有人選擇自己動手，再把成品分享出來。

回文裡的實用提醒

貼文下的討論很短，但有一條值得看：有網友反映「好像只能 checkout 到某個分支才能 pull」，原作者回覆希望對方詳述。也就是說，這款工具目前的分支操作細節可能還有疑問，有興趣的人實際採用前，值得先在自己倉庫上驗證關鍵流程。

對一般開發者的判斷很簡單：如果 monorepo 的速度已經影響每天的 review 節奏，把工具效能納入挑選條件是合理的；至於 GeeTree 本身，等更多實測與回饋出現再評估也不遲。