GitHub 聯合創始人為什麼要重做 Git：GitButler 的真正賭注，不是做更好用的 Git GUI，而是打造 AI Agent 時代的 post-Git 協作基礎設施
title: GitHub 聯合創始人為什麼要重做 Git：GitButler 的真正賭注，不是做更好用的 Git GUI，而是打造 AI Agent 時代的 post-Git 協作基礎設施 date: 2026-04-11 source: https://www.threads.com/@yrzheee/post/DW8C4GIjZQs category: threads tags:
- GitButler
- Scott Chacon
- Git
- AI Coding
- Agent Native
- Social Coding
- Developer Tools created: 2026-04-11 updated: 2026-04-11
GitHub 聯合創始人為什麼要重做 Git：GitButler 的真正賭注，不是做更好用的 Git GUI，而是打造 AI Agent 時代的 post-Git 協作基礎設施
概要
這則 Threads 的切角很準：Scott Chacon 既是 GitHub 聯合創始人，也是《Pro Git》作者、GitHub Flow 的提出者，幾乎是最有資格說「Git 該不該換代」的人之一。
他三年前創立 GitButler，現在宣布拿到 a16z 領投的 1700 萬美元 Series A。這篇貼文認為，Scott 之所以願意「革自己的命」，不是因為 Git 不重要，而是因為：
Git 是為 2005 年 Linux 核心郵件列表協作而生的，而 20 年後，我們卻在教一群 AI Agent 用這套 old stack 來共同寫程式。
從這個角度看，GitButler 的野心並不是做更順手的 Git 包裝，而是重做一層更符合 AI 編程與多方協作的新基礎設施。
這篇真正值得記錄的重點
1. Git 的核心假設，和 AI Agent 時代已經開始錯位
Git 非常強大，但它的原始世界觀是：
- 以人類開發者為中心
- 透過 commit / branch / patch 交換變更
- 假設協作節奏是較低頻、較明確、較可人工理解的
但今天的開發工作開始變成：
- 多個人類開發者 + 多個 Agent 同時工作
- 分支與上下文切換更頻繁
- 很多修改不是手動線性完成，而是來自不同工具與模型反覆嘗試
- 問題不只是 diff 衝突，而是上下文與意圖的丟失
貼文裡引用 Scott 的話非常關鍵：
開發者真正的困難，不是寫不出程式，而是上下文在工具、人、Agent 之間不斷丟失。
這說明未來版本控制的戰場，可能不只是「記錄檔案變更」，而是「維持協作過程中的上下文連續性」。
2. GitButler 想做的不是更好用的 Git，而是 post-Git 協作層
貼文列出的特性其實透露出 GitButler 的方向：
- 堆疊分支（stacked branches）：可以直接在隊友分支上層層開發
- 無限撤銷：減少 reflog / reset 等高風險操作造成的心理負擔
- Agent 原生：從設計之初就考慮 Codex / Claude Code 等 agent 工作模式
- 零遷移：沿用既有 Git 專案，不要求重建整個開發棧
這代表 GitButler 不是要和 Git 正面切割，而是像在 Git 上方加一層新的協作抽象：
保留 Git 的相容性，但重寫人類與 Agent 實際協作時最痛的那一層。
3. 真正的大機會不在「AI 幫你寫 code」，而在「AI 與團隊怎麼一起工作」
很多 AI coding 產品把焦點放在：
- 自動補全
- 自動寫函式
- 自動修 bug
但這篇貼文點出的更大市場是：
- 多個 Agent 怎麼知道彼此在做什麼
- Agent 怎麼理解人類團隊目前的工作狀態
- 分支、意圖、審查、衝突、上下文如何被共同感知
這其實更接近 collaboration infrastructure，而不是單點 coding assistant。
所以 GitButler 的真正賭注是：
當 AI coding 從單兵工具進化成團隊工作流，版本控制與協作介面也必須一起升級。
4. GitHub 當年沒完成的「Social Coding」，可能要在 Agent 時代重做一次
貼文裡提到 GitButler 最有意思的是 Scott 所說的 Social Coding 願景。
GitHub 當年雖然喊出這個口號，但最後更成功的是：
- repository hosting
- PR review
- issue / CI / OSS distribution
而不是真正把「社會化協作」做成版本控制層的核心體驗。
到了現在，Social Coding 可能有了新的含義：
- 不只是人與人協作
- 而是人、Agent、分支、歷史、審查與意圖一起協作
- 系統不只要知道檔案怎麼變，還要知道誰在做什麼、為什麼這樣做、接下來誰來接手
這會把版本控制從 source-of-truth 工具，推向 workflow orchestration 的中心。
5. 這類產品真正挑戰的是「兼容舊世界，又要承接新世界」
GitButler 如果要成立，難點不只是功能，而是要同時做到兩件事：
- 不能逼開發者放棄 Git 相容性
- 又必須提供足夠大的新價值，讓大家願意改工作流
這是為什麼「零遷移」這件事那麼重要。因為 developer infrastructure 最大的阻力，往往不是工具本身不好，而是：
- 團隊慣性很強
- CI/CD、hosting、review、branch policy 都已經綁死 Git
- 沒有人願意為了一點 UX 改善就重建整套流程
所以 GitButler 的真實命題不是「你比 Git 好用多少」，而是：
你能不能在完全不破壞現有生態的前提下，承接 AI 時代的新協作需求。
對 AI Coding 與開發工具市場的啟示
如果把這篇 Threads 往上抽象，它其實在提醒一個更大的產業方向：
- AI coding 的下一站不是更會寫，而是更會協作
- 版本控制的價值會從紀錄變更，擴展到維持上下文
- Branch / PR / merge 這套介面未必能直接承接 Agent 大量介入的開發模式
- 真正的機會在 workflow layer，不只是 model layer
- 誰能接住人類與 Agent 之間的 context loss，誰就可能定義下一代開發棧
我的結論
這篇 Threads 真正值得記的，不只是 GitButler 融資，而是它點出一個越來越清楚的問題：
AI coding 時代最難的，不只是生成 code，而是讓多個人類與多個 Agent 能在同一個上下文裡穩定協作。
所以 GitButler 的價值，不在「把 Git 做漂亮」而已，而在它試圖回答一個 post-Git 問題：
- 如何讓分支更像工作流
- 如何讓變更不再只是 diff，而帶著意圖與上下文
- 如何讓 Agent 不只是 commit producer，而是能感知團隊狀態的協作者
如果這件事成立，那它要替換的不是一個 CLI，而是整個開發協作的心智模型。