本篇文章更新時間：2026/04/11
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
Git 只是起點：從 GitButler 的 Series A，看見版本控制的下一個十年
來源： We’ve raised $17M to build what comes after Git
編輯前言：GitHub 前共同創辦人 Scott Chacon 宣布 GitButler 完成 1700 萬美元募資，但真正值得注意的不是金額，而是他提出了一個大哉問：當前軟體開發的核心基礎設施 Git，是否已經不敷使用？
核心觀點 (Key Takeaways)
- Git 的使用方式與今日的開發流程已經脫節，特別是在 AI 逐漸成為開發主力的時代。
- 開發者真正的痛點不是「產生變更」而是「組織、協作與整合變更」。
- GitButler 想做的不是「更好的 Git」而是「下一代開發協作的底層基礎設施」。
深入解析
Scott 以非常個人的方式回顧 Git 的 20 年歷史：從一個「為寄送 patches 而打造的工具」，長成全球軟體開發的公共基礎建設。然而，他坦言今日我們已經把開發流程硬塞進 Git 的限制裡太久了。
原文寫道：「The hard problem is not generating change, it’s organizing, reviewing, and integrating change without creating chaos.」
這句話我認為抓住了現代開發的真正瓶頸。
1. 開發者不缺產能，缺的是上下文管理能力
AI 寫程式越來越強，但問題反而變成：
- 變更碎片化
- 上下文散落在不同工具（Issue、PR、Chat、Terminal）
- 多個人類與多個 agents 並行工作，產生大量「context loss」
Git 對於這個世界其實沒有原生的支援。
2. Git 仍假設開發流程是一個人、一台 terminal、一條線性的 branch
但現在的工作方式可能是：
- 同時進行多個任務
- 在 coworker 的 branch 上疊加工作
- 多個 AI agent 在背景產生變更
這些都不是 Git 的設計目標。
3. GitButler 的 CLI 是第一步：讓 branch、變更、上下文可以被更直覺地「編排」
Scott 提到 GitButler CLI 的核心功能：
- 堆疊 branches
- 隨時切換與組織變更
- 支援 scripting、agents、人類共用
- 與現有 Git repository 直接相容
換句話說，它不是要推翻 Git，而是要在 Git 之上建立真正符合現代需求的工作流程層。
筆者心得與啟發
讀完這篇發文，我最大的感受是：版本控制並不是一個解決完畢的問題。過去我們以為 Git 已經是終點，但 AI 時代的變更密度、多人協作的複雜度、上下文的碎裂，都讓這套 20 年前的模型顯得吃力。
Scott 提出的願景其實非常大膽：
- 版本控制系統不只是儲存變更，而是要「協調人與 AI 的工作流」。
- 協作不只是 PR、Issue，而是讓團隊工作比單打獨鬥更容易。
- 工具應該能捕捉整個開發歷程的上下文，而不是讓資訊四散在 chat log。
這讓我開始重新思考：未來的開發工具，應該更像「協作大腦」而不是「檔案快照系統」。
如果 GitButler 能把這件事做出第一個版本，那可能真的是 Git 之後的世界雛形。