Git 從沒被設計過：GitHub 共同創辦人重新打造 AI 時代的版本控制

本文整理自《AI + a16z》2026 年 4 月播出的單集。

{{< youtube vJiCnQeYLho >}}

---

二十年不變的工具，遇上全新的使用者

Git 的核心指令從 2005 年誕生以來幾乎沒有改變。GitHub 共同創辦人暨《Pro Git》作者 Scott Chacon 最近在 a16z 的 Podcast 上提到，出版社曾找他寫第三版，他直接拒絕了，因為工具本身幾乎一模一樣，沒什麼好更新的。這件事放在十年前可能只是一個關於開源社群保守文化的小故事，但放在 2026 年，它指向一個急迫的問題：全世界最多開發者使用的版本控制系統，從來沒有被「設計」過，而現在它迎來了一群全新的使用者，AI coding agent。

Chacon 離開 GitHub 後，先創辦了一家語言學習新創（沒成功，但他因此學會德語、娶了德國人、搬到柏林），接著在 2023 年創辦 GitButler，試圖重新設計 Git 的使用者介面層。2026 年 4 月，GitButler 完成了 a16z 領投的 1,700 萬美元 A 輪融資。他的判斷很明確：Git 底層的資料結構和傳輸協議依然優秀，需要改的是上層的操作介面，而 AI agent 的崛起讓這件事從「有空再做」變成「不做不行」。

---

Unix 哲學的遺產與包袱

要理解 Git 為什麼二十年不變，得回到它的起源。Linus Torvalds 和最初的開發團隊信奉 Unix 哲學：做一堆小工具，每個只做一件事，用管道串起來。他們甚至沒打算寫使用者介面，最初的構想是底層提供 plumbing commands（管線指令），讓每個開發者自己用 Perl 腳本包裝成想要的樣子。後來有人寫了統一的 porcelain（瓷器層）指令，因為其他開發者懶得自己包裝，這套指令就被拉進核心，從此成為 Git 的「官方介面」。

這段歷史造成一個根本性的問題：Git 的介面是妥協的產物，而非設計的結果。它試圖同時滿足「機器能用」和「人類能讀」兩個需求，結果兩邊都不理想。Chacon 直言，Git 沒有產品品味（taste），沒有一個人拍板說「介面應該長這樣」。它是委員會式開發的典型產物，好的想法都能進來，但沒有整體的方向感。再加上團隊對向後相容的堅持，幾乎不可能做破壞性的介面改版。

有趣的是，Git 的 Unix 哲學在 AI 時代反而意外地有用。Chacon 觀察到，coding agent 大量使用 sed、grep 這些古老的 Unix 工具，很多年輕開發者第一次看到這些指令，是在 agent 的 tool call 紀錄裡。Git 的 plumbing 指令天生就是為程式化操作設計的，某種程度上比 GUI 更適合 agent。但「能用」和「好用」是兩回事，agent 面對 interactive rebase 完全束手無策，每次執行完命令都想馬上看 status，這些行為模式是原始設計者從未預料的。

---

Agent 作為全新的「使用者人格」

GitButler 最初是一款桌面 GUI 應用程式。Chacon 自己用了 20 年 Git 從不用 GUI，他想做的是一個「真的值得用」的圖形介面，能拖放 commit、視覺化管理多條分支。但過去六個月，團隊的重心轉向了 CLI，原因很直接：agent 不能用 GUI，而 agent 正在成為最重要的使用者族群。

GitButler 現在同時維護 GUI、CLI、TUI 三種介面，共享底層資料結構，但針對不同的「使用者人格」做最佳化。CLI 的部分特別有意思，它提供多種輸出格式：給人看的有提示（hints）的格式、給腳本用的 JSON、以及給 agent 用的 Markdown。最初團隊以為 agent 會偏好結構化的 JSON，結果發現 agent 反而更喜歡人類可讀的格式，因為它會自己寫 Python 腳本去解析需要的資訊，JSON 的嚴格結構反而限制了它的靈活度。

更有趣的是 GitButler 團隊觀察 agent 行為後做出的調整。他們發現 agent 每次執行完一個修改命令後，必定會馬上跑一次 git status。於是他們加了一個 --status-after flag，讓修改命令直接附帶狀態輸出。Chacon 說得很明白：「這種東西你不會為 Unix 哲學做，不會為腳本做，也不會為人類做，但 agent 真的需要。」團隊甚至會回頭看 agent 最近 50 次 tool call 的紀錄，問它哪些操作出了錯、哪些結果不符預期，然後根據回饋調整工具設計。這是一種全新的 UX 研究方法，研究對象不是人，而是 AI。

---

平行分支：多 Agent 同時工作的解法

當多個 agent 同時在同一個專案上工作，版本控制面臨的衝突問題會被放大。目前業界最常見的做法是使用 Git 的 worktree 功能，為每個 agent 建立一份獨立的工作目錄副本。這解決了「不踩到彼此」的問題，但也帶來一個根本性的缺陷：完全隔離意味著 agent 之間毫無感知，等到要合併時才發現衝突，往往為時已晚。

GitButler 的核心創新是「平行分支」（parallel branches）。多個 agent 在同一個工作目錄中同時操作，底層透過一個隱藏的 mega merge 機制保持一致性。當一個 agent 修改了某個檔案，其他 agent 能即時看到變更，自動避開衝突。如果兩個 agent 真的需要編輯同一個檔案但方向不相容，系統會自動將其中一個的分支「堆疊」（stack）在另一個之上，各自繼續在自己的堆疊層中 commit，最終這些堆疊分支可以按任何順序合併。

Chacon 的共同創辦人 Kiril Videlov 展示過一個實際案例：兩個 agent 同時搶著編輯同一個檔案，其中一個自動將分支堆疊到另一個之上，然後兩邊繼續各自 commit，互不干擾。這在原生 Git 裡是做不到的，interactive rebase、amend commit、在堆疊中移動 commit 這些操作，原本就不是為並行場景設計的。

團隊甚至嘗試過讓 agent 之間建立一個聊天頻道，三個 agent 同時工作時可以互相通報進度。Chacon 坦承他非常想把這個功能上線，因為看著 agent 互相對話的畫面實在太酷了。但實驗結果顯示：直接通訊並沒有帶來效益。agent 只需要看到對方的檔案修改就夠了，它會自動推測對方在做什麼、自動迴避衝突區域，額外的溝通管道反而增加了無謂的開銷。

---

「下一個 GitHub」不會長得像 GitHub

Chacon 對 GitHub 的未來看法很務實。他認為 GitHub 的規模同時是優勢和劣勢：全世界的開發者都在上面，任何新功能瞬間觸及最大受眾，但也因此很難快速轉向。在 AI 工具鏈每個月都在變化的當下，大公司的審慎反而可能成為落後的原因。

他用 GitHub 自身的歷史做類比：GitHub 之前是 SourceForge 和 Google Code，但 GitHub 看起來完全不像它們。它解決了一組全新的問題，用了一套全新的原語（primitives）。同理，「下一個 GitHub」也不會長得像 GitHub，它會解決我們現在還無法完全描述的協作需求。

Chacon 也對現有的開發原語提出質疑。Pull Request 是 GitHub 最重要的創新之一，但他認為基於分支的程式碼審查本身有結構性問題：因為合併的單位是整條分支，開發者不太在乎個別 commit 的品質，commit message 淪為「oops」和「fix typo」的堆積場。他更傾向回到 patch-based review（基於 patch 的審查），讓審查單位是有意義的程式碼變更，而不是一整條可能夾帶垃圾 commit 的分支。

至於 code review 本身，Chacon 也不客氣地說了實話：大多數開發者根本不會逐行看完整個 PR，頂多掃一眼確認沒有明顯的問題或外洩的 API key 就按 approve。真正有效的 review 是把程式碼拉下來實際執行和測試，而這恰好是 agent 擅長的事。未來的 code review 很可能會變成 agent 先跑完所有測試和靜態分析，人類只需要看 agent 標記出來的問題清單。

---

我的觀察

Chacon 談到一個細節讓我印象深刻：GitButler 團隊會讓 agent 回頭看自己的操作紀錄，告訴開發者哪些工具設計讓它困擾。這本質上是一種「AI 使用者研究」，而且 agent 比人類受訪者更誠實，因為它不會礙於面子說「還好啦」。當我們開始認真把 AI 當成一個需要服務的使用者族群，而不只是一個可以調用的工具，開發者工具的設計邏輯就會徹底改變。Git 的故事只是開端，接下來每一個開發者日常使用的工具，都會面臨同樣的問題：你的介面是為人設計的、為機器設計的、還是兩者都沒設計過？