Git 已经是开发者的基础设施十年二十年甚至没有真正的挑战者。正因为如此当 Zed Industries 丢出“Git 已经落伍了”这种标题的时候第一反应大概率是“又一个标题党”。但如果你了解 Zed 这家公司——创始人 Nathan Sobo 之前做出了 Atom现在做的 Zed 编辑器走的是高并发实时协作路线——你就会明白他们大多不是在搞营销而是在认真宣布一件大事。这件事就是 Delta一个被定位为 Git 替代方案、主打“无需拉取请求”的代码审查系统。它背后不是一个简单换掉 git 命令的噱头而是对“版本控制”这整件事的重新设计。今天这篇不吹不黑我从 Delta 想解决的问题、它和 Git 的核心差异、以及 AI 时代为什么注定要有人做这件事这几个角度慢慢拆开讲。1. 一个编辑器团队宣布要做 Git 替代品这事为什么值得认真得先把 Delta 出现的背景理清楚。Zed 不是那种“顺手做个 IDE 插件”的小团队他们从编辑器底层就开始做协作优先。你在 Zed 里打开一个项目天然就能共享给同事光标、文件树、终端输出几乎无延迟同步。这个底子决定了他们对“代码如何被多人同时改动”这件事有比普通 Git 工具链更切身的痛感。Git 的设计模型本质上是分布式快照。每个人在本地提交、开分支、合并然后通过 remote 伺服。这个模型在开源协作上赢了因为它是异步、去中心化、以文本差异为中心的。但到了业务开发团队尤其是 AI 辅助编程开始普及之后痛点非常明显多人同时改同一个文件“合并冲突”变成常态而不是例外。开发者的真正工作被挤压在“创建 PR”“等 review”“rebase 再 push”这些流程动作里。代码审查变成了一个隔离在浏览器里的异步环节跟编码语境完全切割。AI 可以帮助写代码、改 bug但 AI 生成的代码同样要送进这套 PR 流转机制里瓶颈就从“写代码”转移到了“审代码”。Zed 团队正是从这些经验出发认定 Git 那套建立在“文件快照 分支隔离 手动提交”之上的协作模型在 AI 时代已经变成效率瓶颈。Delta 的完整细节目前还像一篇设计蓝图但整体方向非常明确把版本控制从“文件级别的提交历史”推向“语义层面的实时协作轨迹”。这个方向放到业界来看也是第一次有编辑器团队敢动这个根基。2. 拉取请求模型的摩擦清单表面上够用实际上一直在付隐形税如果只看 Git 本身它作为版本控制工具是合格的。真正让人觉得“吃力”的是建立在 Git 之上的跨团队协作流程尤其是拉取请求Pull Request。2.1 合并冲突是最廉价的失败方式Git 的合并基于文本。它并不理解你的代码意图。两个分支各自改了同一个文件的几行Git 会告诉你有冲突冲突解决通常需要手动逐行选择。这还不算最伤人的部分——真正伤人的是很多冲突其实在语义层面完全重合你不得不停止编码思路去处理一堆毫无营养的粘连操作。到 AI 辅助编码的时代这个痛苦会被放大。因为 AI 生成代码时常常会大幅重构一个函数它不会刻意避开别人正在改的区域。于是“多个 AI 助手同时在改同一个代码库”的场面一旦出现文本层面的 merge 会成片成片地冲突人工解决成本高到不可接受。2.2 审查变成了异步的“线下会议”传统 Git 工作流里写代码和审代码是严格分开的。你把分支推到远端点击创建 PR然后等着别人有空来看。等 reviewer 打开 PR 页面时他对你写作时的上下文一无所知只能从 diff 反推你的意图。这个过程中信息损耗极大。我自己的体会很直接写一个功能的时候我会记得“这里为什么要用缓存”“那里为什么临时跳过校验”但 PR 描述通常只写两三句概括。等两天后别人来 review看到一堆疑问评论我可能得重新读一遍代码才能想起来当时的意图这种来回非常消耗精力。2.3 分支模型把“协作”默认为“隔离”Git 分支模型的核心前提是大家应该在各自动的分支上独立开发最后再合并。这个假设天然把协作放到了事后。但在实际团队里人与人之间的协作不是“各改各的再合并”而是需要经常性地互相看代码、讨论设计、实时修改同一段逻辑。Git 的分支隔离让这些动作都变成了“先合并再说”或者“先在聊天窗口传来传去”效率非常低。2.4 AI 时代的码力溢出让审查与管理成为瓶颈过去瓶颈是“写不动”现在有 AI 辅助一个人一小时能写几百行。但代码审查还是靠人评审者读代码的速度没怎么涨。码力溢出之后PR 队列越积越长审查变成走个过场。最终的结果是代码质量并没有因为 AI 提升反而因为审查赶进度而下降。这就是 Delta 为什么把“代码审查”当作切入点而不是去抢“更快的提交”这种小事。3. Delta 的核心主张版本控制从文件快照转向持续协作轨迹现在可以正面聊 Delta 了。按目前披露的方向它和 Git 有四个层次性的差异。3.1 提交与服务端Git 的核心对象是不可变的提交Delta 理解的最小单位是“真实发生的变化”。这些变化可以被记录成某种逻辑上的操作轨迹而不仅仅是一行行文本 diff。这也意味着你不再需要主动完成带着消息的提交才获得历史记录。编辑器的每一次修改都会被持续捕捉形成一个像“时间线”一样的连贯历史。这跟 Git 的“手动控制提交点”相比更接近人在真实工作中连续修改代码的状态。3.2 分支与空间Delta 把 Git 分支的逻辑改成了所谓的“空间”。你在同一个项目里可以同时存在多个空间每个空间对应一个工作上下文。但重点在于这些空间之间不是完全隔离的。它们共享同一个底层的持续变化流更像是列表里不同的视图而不是平行的宇宙。这样做的好处是多人协作时你可以很容易看到别人正在空间里改什么而不需要先做一次 fetch 和 checkout。冲突当然还会存在但 Delta 的设计思路是通过共享上下文让冲突提前暴露、提前解决而不是在最后合并阶段一次性爆发。3.3 合并与解决之前在桌面协作工具里文本合并的做法已经相当成熟比如 Google Docs 的多人同时编辑就不需要用户去解决 merge conflict。Zed 团队把这种“协作文档”的思路带到代码上靠的是操作级合并。如果你和别人改的是完全不同的代码块系统会自动合并如果改到同一处协作工具可以立刻把分歧呈现在所有参与者面前而不是Review后再来回打乒乓球。3.4 数据模型天然更适配 AI这一点被很多讨论忽略但我认为它有可能是 Delta 真正的长期优势。Git 的数据模型是“对象图”AI 要从里面提取语义信息必须做额外的抽象工作。Delta 直接把历史记录为变化轨迹配合自然语言描述AI 就可以更高效地回答这类问题“这个函数为什么从第 3 行开始变了”“谁在上周重构过模块 A”“我当前空间里没提交的改动有没有可能和 main 上游的某个近期改动冲突”传统 Git 做不到这种语义级问答因为它的基础模型太底层了。Delta 把变化本身变成头等公民AI 理解和辅助代码审查的难度就会大幅下降。以我个人的判断这一点才是“AI 时代 Git 落伍”论点的真正落点。Git 不是被 Delta 打败的而是被 AI 对代码语义理解的需求淘汰的。4. 无 PR 模式的真实形态审查从流程变成一种状态“无需拉取请求的代码审查”这句话听起来很激进其实拆开看并没有那么玄幻。它改变的是代码被审查的时间和空间。4.1 审查不再发生在“推送之后”传统 PR 模式里代码只有完整实现后才会进入审查。Delta 模式里变化流是持续记录的审查可以随时发生。同事不需要等你 push就能看到当前空间里正在改什么AI 助手也能实时监控你的改动即时给出建议或警告不需要等一个“草稿完成”的信号。这对大型重构尤其有意义。以前大重构的 PR 几千行 diff评审者根本无从下手。如果在重构最初始的阶段就进入持续审查每个步骤都是清晰且小粒度的评审压力会大幅减轻。4.2 审查变成对话而不是单向批注在 Git 的 PR 系统里你提交代码评审者写评论你改代码再 push 新 commit反复几轮。这本质上是异步的书面沟通效率和体验都很差。Delta 模式下评审评论直接绑定到代码行和具体的变化双方可以实时进行文字甚至语音讨论。评审不再是一个悬置状态而是代码演进过程中的自然组成部分。这更像两个人坐在一起“结对编程 随时反馈”而不是隔着浏览器窗口互相丢批注。4.3 AI 充当持续评审员这里要说到热词里反复出现的那几个AI、代码审查、Zed。Zed 编辑器里已经集成了 AI 助手Delta 大概率会借此形成一个“预审”环节。AI 能在你写着代码的时候就发现问题潜在的空指针、逻辑边界、风格不一致、新的变更影响到的下游模块。相当于每个开发者身边都有个永远在线的初级评审员把大量低级问题提前拦住。人类评审者只需要关注更高级的设计问题、业务逻辑和长期可维护性。如果这种 AI 预审机制真能落地那“拉取请求”这个模式确实会显得效率极低因为绝大多数评审意见在代码成型之前就该被消化掉。5. 一个更现实的图景Delta 会先取代什么再取代什么你可能会问Delta 说得头头是道那我现在的 Git 仓库、GitHub 工作流、CI/CD 系统怎么办我的判断是Delta 短期内不会“删掉 repo”但会重构 repo 在团队协作中的位置。5.1 先替代的是“PR 审查层”最容易被 Delta 替代的不是 Git 本身而是 GitHub 上的 Pull Request 页面。因为 PR 本质上是一种基于文件差异的审查 UI并没有深刻绑定 Git 的对象模型。Delta 完全可以保留现有 Git 仓库作为数据底座但在上层提供一个持续协作 AI 审查的交互层。你继续用“提交”作为里程碑但日常的小步变更不再需要走 PR 那套重流程。5.2 再影响的是“分支策略”业务团队的分支策略往往很复杂main、develop、release、hotfix、feature/xxx。这些策略大量精力花在“隔离”和“排队”上。Delta 的空间/上下文模型如果足够成熟会让大部分 feature 分支失去存在必要。不是因为没有并行开发而是因为并行不需要彻底隔离了。热修复、发布分支这些运维意义上的分支则会更长期地保留下来。5.3 最难替代的是“历史审计”如果你的项目需要严格合规审计比如要追溯“某一行代码是谁在什么时间改的、携带什么提交信息”Git 的不可变提交图仍然有绝对优势。Delta 那种持续变化流更适合日常工作但作为审计底稿需要再叠加快照或里程碑机制。我比较怀疑 Delta 在这些场景中会把 Git 历史保留为一个“归档层”两者共存而不是你死我活。5.4 协作模式的改变是不可逆的更重要的是观念上的变化。过去我们习惯“写好代码再给别人看”Delta 暗示的是“写代码的过程从一开始就应该是共享和可审查的”。这个思维方式一旦被团队接受就很难回到过去。刷完一圈实际体验和相关资料后我的态度是不要急着站队说“Git 落伍”或“Delta 是花架子”而应该把它当成一次对协作本质的再思考。那些整天被 PR 流程、合并冲突、review 等待耗费的团队尤其值得关注 Delta 的进展。就算最后 Delta 没有完全取代 Git它也会迫使现有工具链把“AI 辅助审查”和“持续协作”当成一等公民来对待这已经是在改变游戏规则了。