Zed 的 Git 暂存区更新

2026年7月Zed 优化了git部分暂存的可视性。它没有引入新的 AI 模型没有重构编辑器内核只是做了一件看起来很小的事让 Git 的暂存和未暂存变更在界面上清晰地分开了。对于长期使用 VS Code 的开发者来说这几乎是 Git 面板的“出厂设置”。但在 Zed 这里这件事的落地过程恰好揭示了 Zed 与 VS Code 在工具哲学上的一个深层分水岭。迟到的“U”标识与设计哲学的碰撞zed团队 在描述这个问题时说得很直接长期以来Zed 的 Git 面板将暂存和未暂存变更混在一起让他很难一眼看出哪些更改还没被 stage导致经常漏提代码。他遇到的困境是Zed 将“未提交的变更”全部塞进一个 Multibuffer开发者无法像在 VS Code 中那样清晰看到两个独立的列表。但有趣的是这个新特性的实现经历了漫长的拉锯。核心工程师 cole-miller 最初的想法是将“未暂存变更”做成现有Uncommitted ChangesMultibuffer 的一种“模式”或“过滤器”而不是一个完全独立的面板。甚至在早前的zed的设计中Zed 团队还津津乐道于他们独创的“差异的差异”diff-of-diffs设计——即将暂存和未暂存的 hunks 交错显示以避免在键盘操作时因 hunk 移动导致焦点丢失。这暴露了 Zed 的一个核心纠结是坚持自己对“键盘流”和“极简”的独特理解还是向开发者已经习惯的、更通用的心智模型靠拢最终社区的声音占了上风。用户反复提出的需求最终促成了这次改变。有些开发者直言他无法切换到 Zed直到其在 Git 面板上实现与 VS Code 对等的功能——能够清晰地按暂存状态排序并查看对应的 diff。他的诉求非常具体当点击一个未暂存文件时看到的是它和暂存版本的差异当点击一个已暂存文件时看到的是它和最新提交的差异。这正是 VS Code 早已打磨成熟的工作流。这次zed提供了一套适配 Zed 整体交互风格的全新未暂存变更界面方案。不再按单个文件展示变更而是将已暂存差异、未暂存差异分别放入独立多缓冲区沿用当前「未提交变更」的实现思路一个独立的Staged Changes已暂存变更Multibuffer与Uncommitted Changes并列。一个U标识出现在有未暂存变更的文件旁作为明确的视觉提示。工具栏上出现了Unstaged | Uncommitted的切换开关方便在两种视图间快速切换。至此Zed 终于以一种符合自身“Multibuffer”哲学的方式补上了 Git 工作流中关键的一环。下面看看实际效果左侧为现有「未提交变更」视图中间是「已暂存变更」缓冲区右侧为「未暂存变更」缓冲区可供对比参考你可以通过点击左边的u来打开右边的视图或者通过右键选择staged changes火unstaged changes不仅仅是分两栏隐藏在“小改动”下的架构重构这个功能看似只是把列表分成了两栏但其背后的改动远比想象中复杂。正如 cole-miller 在合并时感慨“最终这个特性对 Git 代码的改动比我想象的要大得多。”为什么因为 Zed 此前那套优雅的“diff-of-diffs”设计在处理“共享基础文本”时遇到了挑战。要让“暂存”和“未暂存”两个 Multibuffer 能基于同一个HEAD文本快照正确地计算差异并实时响应“暂存/取消暂存”的操作需要对底层的GitStore和BufferDiff进行重构。这意味着为了在 UI 上“分两栏”Zed 团队不得不重写了部分核心数据流。看法当“轻快”开始理解“工作流”过去我们把 Zed 和 VS Code 的竞争简单归结为“性能”与“生态”的对决——Zed 用 Rust 换来极致的轻快VS Code 靠庞大的插件生态构建了护城河。但这个 Git 特性的落地过程让我们看到了另一层竞争“编辑器”与“工作区”的对决。有开发者敏锐地指出了这一点Zed 追求的是极致的“编辑体验”启动快、响应快而 VS Code 的真正优势在于“环境记忆”——它能记住你打开的终端、运行的历史命令、分屏布局让你在切换任务后能瞬间恢复上下文极大地降低了心智负担。VS Code 的 Git 面板正是这种“环境记忆”的一部分它将终端的git status转化为了一个持久的、有组织的工作区状态。虽然 Zed 目前依然缺少类似 IDEA 的自定义变更列表Changelist等重型功能但这次更新与其 Git 面板的其他重构如独立的排序、分组、树形视图控制一起昭示了它的发展路径在不牺牲“快”和“键盘优先”的核心理念下逐步吸纳那些已被验证的、能真正提高效率的工作流模式。当“快”开始理解并融入你的工作流它就不再只是一个工具而是你编程节奏的一部分。