GitHub的聯合創始人Scott Chacon最近籌集了1700萬美元，他的目標很簡單：

干掉Git！

作為絕對的Git資深玩家，豆瓣9.0分《Pro Git》的作者，一個靠Git吃飯，成名，發財的人，Scott Chacon為什么要“反水”？

這1700萬美元，是要做一個“Git之后的東西”：GitButler。

GitButler會保存Git的底層能力（DAG，Commit，History），然后重做上層交互模型，最終實現一個AI編程時代的版本管理工具。

01

Git出了什么問題？

Git堪稱開發者世界中最讓人又愛又恨的工具，它的底層抽象非常優雅，核心的數據結構只有四種：Blob、Tree、Commit、Tag。

這四者加上哈希引用，居然就能表達整個歷史樹！

設計極度簡潔，但威力無窮。

這和 UNIX 哲學一樣，少而精，組合強大。

所以，Git經受了20多年的考驗而經久不衰。

不過，Git的分布式架構、暫存區（Stage）機制、分支管理策略以及復雜的命令組合，也讓很多程序員在使用的時候陷入迷茫和困惑，熟練了以后才能得心應手。

到了AI編程時代，類似Claude Code的工具讓程序員的生產率暴增，程序員完全可以同時驅動幾個Claude Code干活。

一個負責新功能開發，另一個處理bug修復，還有一個做代碼重構，同時運行互不干擾。

但是，傳統的Git分支模型面對并行的處理就力不從心了，因為你只有一個工作目錄，需要不停地切換分支：

先在Branch A上開發新功能，然后到Branch B上修復Bug，再到Branch C上做代碼重構。

本來可以并行執行的功能，變成了順序執行，你需要瘋狂切換。

你可以為每個AI會話都創建一個新的工作目錄（git worktree），這意味著反復運行項目的初始化設置（npm install等），效率低不說，當不同AI修改同一文件時，你還要和自己制造的合并沖突做斗爭。

02

GitButler如何解決？

GitButler的解決方案很簡單：只有一個工作目錄，但是可以創建多個虛擬分支。

拿之前的例子來講，你可以同時開3個Claude Code，一個開發新功能，一個修復Bug，還有一個做代碼重構，它們在同一個工作目錄中干活。

等活兒干完了，你可以查看不同的代碼修改，然后再添加到不同的虛擬分支去。

先干活，再生成分支，感覺和之前的工作方式完全反過來了，對吧？

但是有個問題，如果各個功能之間修改的代碼出現了交織的情況，程序員很難把他們區分開，怎么添加到不同的分支呢？

GitButler在這一點上很聰明，它通過Claude Code的生命周期鉤子實現了一個精妙的自動化流程：

AI開始編輯文件，GitButler能收到通知，自動創建虛擬分支，然后把該AI所做的所有修改都放到這個分支中。

這就真正地讓AI成為了一個“并行開發者”，在其隔離的環境中貢獻著干凈、可審閱的代碼。

當然，GitButler增加的新功能遠不止此，還包括：

分支堆疊：將一個大的功能拆分成若干個相互依賴的小分支，從而加快審查速度，并使集成能夠逐步進行。

人工智能助手：讓AI來處理這些繁瑣的工作:自動生成分支名稱、提交信息和PR描述，從此不用寫“做了一些改進”之類無用的comment了。

對Commit進行修改： 把“后來發現的代碼問題”，塞回“當時該提交的那個 commit 里”，同時自動處理所有歷史關系，這樣就避免了補丁疊補丁，或者rebase的操作。

03

激烈爭吵

GitButler的作者公布了融資額度以后，國外社交媒體上也吵翻了天，質疑聲一片：

“Git根本沒問題，你在解決一個不存在的問題”

“這些功能早就有了（worktree,branch）”

“你這是為了迎合AI，強行改變成熟的工作流程”

“多個AI同時開發，會導致更嚴重的代碼混亂！”

當然也有人贊賞：

“Git 的UI確實很爛”

“并行開發（尤其 AI agent）確實是新需求”

“更好的 code review 顆粒度”

“嘗試突破 Git 的歷史包袱”

總之，反對派的觀點是，Git已經是正確的抽象，不要為了AI而亂改，更不能拿把基礎設施私有化（GitButler并不是完全的開源軟件）。

支持派則認為：Git是歷史遺產，工具應該適應AI和新的開發模式。

所以，GitButler 的爭議，本質不是工具之爭，而是：“未來軟件工程該圍繞 Git，還是圍繞 AI 重構？”

04

Git不是終點

就在GitButler拿到1700萬美元融資的同時，另一個信號也耐人尋味：2026年2月，GitHub前CEO Thomas Dohmke創立的Entire以3億美元估值完成6000萬美元種子輪融資，領投方稱其為“開發工具史上最大種子輪”。

Entire的野心更大：不止要替代GitHub，而要為AI寫代碼這件事兒，重新打造一整套開發基礎設施，它不僅要保存代碼，還要保存“上下文”（提示詞，推理過程，工具調用，約束條件.....）

兩位曾經的Git生態守護者，如今卻雙雙站在了Git的對立面。

原因很簡單，整個軟件行業又要開始一場范式轉變：“從以人類為中心的手工業協作，轉向以智能體為中心的工業化生產。”

Git 2005年誕生，隨后席卷全球，把SVN等版本管理工具打得潰不成軍。

我當時覺得它的設計巧妙而精良，至少也會用個三五十年吧，但沒想到，僅僅20年過去，AI時代的編程就向它發出了挑戰。

Git還能流行多久，GitButler能不能上位，我們并不知道，我們知道的是：

Git不是終點，它和SVN一樣，是一個時代的答案。