我从来不是拉取请求的忠实粉丝。在引入代理之前，更容易相信对快照进行评论的仪式是一种有效的协作软件的方式，但这对Zed团队来说从未真正奏效。我们经常在同一个工作树中一起工作，通过在编写代码时讨论代码来建立信任和共同理解。GitHub 不允许你在提交和推送之前讨论代码，但到那时，我们最重要的讨论通常已经结束。因此，在2021年，我们创办了Zed，旨在超越提交的限制。我们的计划是构建一个配得上世界顶级开发者的编辑器，然后在其中提供更好的协作方式。当时我们未曾预见的是，在与代理协作时，我们花费了数年思考的人与人合作的背景下所面临的问题将变得更加重要。不断产生代码的对话正逐渐成为我们软件的真实来源。这种对话是持续展开的，必须与代码在变化时进行交叉引用。Git围绕离散的提交组织，从未设计来支持这一点。所以我们正在构建一种支持这一点的东西。我们称之为DeltaDB，一种基于单一一致抽象的新型版本控制系统，它将你与代理的对话及其编辑的工作树转化为共享的工件。自我去年秋天首次谈到它以来，我们取得了很多进展，随着几周内即将发布的测试版，我非常高兴可以分享我们将要推出的内容。每个操作，不仅仅是每个提交，DeltaDB会将你的工作分解成一系列细粒度的增量变更（delta）。Git在每次提交时捕获快照，而DeltaDB则捕获每一个操作，并为每个操作赋予一个稳定的身份。因为每个增量都可以单独被引用，你可以在它的发展中的任何时刻指向代码，即使它不断变化。这使我们可以对工作树在演变过程中进行版本版本控制，与推动其发展的对话一起。消息和其产生的编辑并排记录，因此它们不会彼此漂移。因为DeltaDB嵌入了无冲突的复制工作树，许多人和代理可以在不同的机器上同时编辑相同的文件。这些文件是真实的：代理通过终端在其中工作，你可以随时将整个工作树挂载到磁盘，以便使用你自己的工具。源代码现在是源对话。因为每个引用是锚定在一个增量上，而不是行号，它在代码在其下方移动时得以存活。从过去对话中的任何一行，你都可以跳转到当前的代码或代理写作时的代码。从任何代码行中，你都可以找到产生它的对话以及自那时以来所有接触过它的对话。代理也可以利用这一点。他们可以了解自己所接触的代码背后的背景，或召集曾经在其上工作的代理，并询问它为什么是以这种方式编写的。你不需要提交就能协作。我们真正想要的很简单：与代理的对话成为你需要进行的唯一对话。团队成员可以在工作仍在进行时加入，与进行工作的代理交谈，并在进行中进行注释，而无需等你先提交和推送。拉取请求、审核线程和内联评论都是为了在事后将讨论重新附加到代码上，因为讨论和代码生活在不同的地方。将它们放在同一地方，仪式就消失了。Git和CI依然存在于它们擅长的地方：运行检查并将你连接到世界的其余部分，而不是成为协作被迫发生的地方。接下来会发生什么 软件现在在对话中塑造，而不是在提交中。DeltaDB是为此构建的版本控制，几周后我们将开始将其交给早期用户。如果你想成为第一批尝试的人，请加入等待名单。相关帖子 请查看Zed团队的类似博客。寻找更好的编辑器？你可以今天在macOS、Windows或Linux上尝试Zed。立即下载！我们正在招聘！如果你对我们博客中讨论的话题充满热情，请考虑加入我们的团队，帮助我们推动软件开发的未来。