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 辅助审查”和“持续协作”当成一等公民来对待，这已经是在改变游戏规则了。
