Git 之后，版本控制要重写一遍了？GitHub 联合创始人 Scott Chacon 的新公司拿下 1700 万美元
一笔不算夸张的钱，一个很大的野心
在 AI 创业动辄上亿美元起步的今天，GitButler 这笔 1700 万美元的 A 轮融资，单看数字其实不算最炸裂。但如果你知道创始人是 GitHub 联合创始人 Scott Chacon，这件事的味道就不一样了。
GitButler 这轮融资由 a16z 领投，Fly Ventures 和 A Capital 继续跟投。表面上看，这是一家开发者工具公司完成了新一轮融资；往深一点看，这是 Git 时代的重要参与者，开始认真下注“Git 之后的软件协作基础设施”。Scott Chacon 在公告里说得很直接：他们不是想做一个“更好的 Git”，而是想重建软件如何被协作地生产出来。
这话听起来有点大，甚至有点像创业圈标准口号。但它确实踩中了今天开发者最真实的痛点。过去十几年，Git 从一个偏极客、偏底层的版本控制工具，变成了全世界软件开发的公共底座。你可以不会写 Makefile，不懂 Linux 内核补丁流程，但你大概率每天都在 commit、push、rebase、resolve conflict。Git 成了空气，没人天天夸它，但谁也离不开它。
问题在于，空气有时候也会闷。尤其是当今天的软件开发，不再只是“一个程序员、一条分支、一个终端窗口”那么简单的时候。
Git 没坏，但它越来越像一把老扳手
Git 最初诞生于 2005 年，是为 Linux 内核那种分布式、邮件列表式的协作方式设计的。它的哲学非常漂亮：去中心化、可追溯、强分支模型、离线优先。今天回头看，这套设计依然堪称工程史上的杰作。
但杰作不等于永远适配一切。
如果你现在是一名普通的软件工程师，你的日常很可能是这样的：一边在 IDE 里写代码，一边让 Copilot 或其他 AI 工具帮你生成补丁；你在 Slack 或 Discord 里跟同事讨论需求；项目管理在 Jira、Linear 或 GitHub Issues；代码评审在 Pull Request 里；上下文散落在各种聊天记录、PR 描述、提交信息和脑内记忆中。等到合并冲突真正爆炸时，往往已经是开发链路的最后一公里。
Scott Chacon 提到一个特别准确的判断：开发者的困难，很多时候不是“不会写代码”，而是“上下文在工具与人之间不断丢失”。这句话几乎就是当代软件协作的病历摘要。AI 的加入并没有自动解决这个问题，反而把问题放大了。因为现在不只是你和同事在改代码，还是你、同事、多个 AI agent 一起改代码。原来的工作流已经够拧巴了，现在又硬塞进更多角色，结果当然更像早高峰地铁。
所以，GitButler 想改的并不是 Git 的对象模型本身，而是围绕变更组织、审阅、堆叠、回滚、并行处理的那层体验。说白了，它盯上的不是“版本控制”四个字，而是“协作控制”。这点很关键。
GitButler 想做什么：不是替换 Git，而是包住 Git
GitButler 最近推出了 CLI 技术预览版，主打 GitHub Flow、短生命周期分支、trunk-based development 这类更符合现代团队节奏的工作方式。它强调 stacked branches、多任务并行、操作可回退，以及更自然地组织变更。
如果你熟悉 Graphite、Sapling、jj（Jujutsu）这些近年冒头的工具，就会发现整个行业其实都在往同一个方向拱：Git 还是那个 Git，但开发者越来越不想直接面对它那套古典而锋利的原始交互。大家想要的是更贴合现代协作的抽象层。
Graphite 主要在 stacked diffs 和代码评审效率上打得很猛，尤其受到大团队欢迎；Meta 推出的 Sapling 则是从大型工程组织内部实践里长出来的，强调更流畅的提交与历史管理；Jujutsu 则试图重新发明一套更现代的版本控制交互逻辑，甚至有点“给 Git 套上时间机器”的意思。GitButler 的不同之处，在于它显然不满足于做一个“命令更好记、图形界面更顺手”的工具，它想把“人与人、人与 agent、agent 与 agent”的协作关系一起纳入版本控制的语境中。
这是一个很有吸引力的叙事。想象一下，如果未来版本控制工具不只是保存 commit，还能保留一段修改背后的上下文：这个改动是谁发起的，AI 提过哪些方案，团队讨论里为什么否掉了某种实现，某位同事的上游分支正在变化，系统提前预警你们两小时后会发生冲突——这就不再只是代码仓库，而是软件生产过程的“运行记录仪”。
这也是 Scott Chacon 提到“Social Coding”时最让我有感的一点。GitHub 当年让开源协作变得前所未有地顺滑，但团队协作这件事，严格说并没有被根本重做。问题列表、看板、PR、外部聊天工具，这些零件都有，但它们并没有真正长成一个统一的协作系统。很多信息依旧是一次性的、易丢失的、不可追踪的。我们今天说自己在做“协同开发”，很多时候其实只是把碎片扔进更多系统里。
AI 代理时代，版本控制为什么突然又重要了
过去两年，AI 编程工具最大的变化，不是它们能写多少代码，而是它们开始“主动做事”。从补全到生成函数，从生成函数到改多个文件，再到能按照 issue 自主完成一个小任务，AI 正在从助手变成半自动协作者。接下来再往前一步，就是多 agent 并行工作。
这时候，版本控制就不再是后台基础设施，而会重新成为最前台的系统协调层。因为 AI 最大的问题不是“写不出来”，而是“写出来之后怎么安全地进入主线”。谁先改、谁后改、哪些改动应该捆绑、哪些应该拆开、冲突如何提前发现、审阅上下文如何保留——这些都是老问题，但在 AI 时代会指数级恶化。
GitButler 试图解决的，恰恰是这一层。如果它做成了，它的价值甚至不只是提高几个百分点的工程效率，而是可能重新定义“代码变更”这个基本单位。未来你提交的也许不再只是一个 commit 或 PR，而是一组带有语义、上下文、协作者关系、AI 参与轨迹的变更包。
不过，理想很丰满，现实也不会手下留情。开发者工具最大的门槛，从来都不是技术实现，而是习惯迁移。Git 之所以顽强，不只是因为它功能强，而是因为它已经嵌进所有平台、CI/CD、IDE、团队规范和开发者肌肉记忆里。任何想要“重写 Git 工作流”的产品，都必须回答一个现实问题：你能在不打断现有工程体系的前提下，提供足够显著的收益吗？
GitButler 的一个聪明点在于，它没有喊“推翻 Git”，而是强调自己可以直接进入现有 Git 项目。这是务实路线，也是唯一有机会的路线。开发者通常愿意尝试新工具，但前提是别让他先读 40 页迁移文档，再冒着搞坏仓库历史的风险。
这件事真正值得关注的，不只是 GitButler
我更愿意把这笔融资看成一个行业信号：版本控制这个沉寂多年、看起来像“已经完成”的领域，又开始重新活跃了。
过去很长时间里，开发者工具创新集中在云原生、CI/CD、可观测性、低代码和 AI 编程助手上。版本控制本身像一层稳定地基，大家默认它不会变，也不太敢动。但现在，随着 AI 大量进入代码生产环节，地基突然又成了瓶颈。你会发现，最古老的问题重新变成最新的问题。
这和数据库、浏览器、终端这些基础工具的历史有点像：当上层应用方式发生变化时，底层抽象就会被迫更新。不是因为老工具失败了，而是因为世界已经换了运行方式。Git 曾经完美适配开源分布式协作时代，而今天的软件生产，越来越像持续流动的多人实时编辑现场，中间还夹着一群不睡觉的 AI 同事。老扳手还能拧螺丝，但未必适合修一整条自动化装配线。
当然，争议也会很快出现。把更多上下文、聊天、agent 轨迹纳入版本控制层，到底是效率革命，还是又一轮工具膨胀？开发者会不会反而被更多元数据包围？团队是否愿意把本应短暂的讨论、试探和失败，也沉淀成某种长期记录？还有一个更棘手的问题：当“代码是谁写的”越来越难定义时，审阅责任和决策责任该落在哪？
这些都没有标准答案。但恰恰因为没有答案，这个赛道才重新变得有意思。
从记者视角看，GitButler 今天公布的不是一条普通融资新闻，而是一份挑战书：挑战 Git 时代形成的协作习惯，也挑战我们对“版本控制究竟控制什么”的理解。软件世界里，真正重要的变化往往不是某个模型多了几个 benchmark 分，而是那些看似老旧、其实掌管秩序的底层系统开始松动。GitButler 这次，就是冲着那层秩序去的。