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 面板的其他重构（如独立的排序、分组、树形视图控制）一起，昭示了它的发展路径：在不牺牲“快”和“键盘优先”的核心理念下，逐步吸纳那些已被验证的、能真正提高效率的工作流模式。
当“快”开始理解并融入你的工作流，它就不再只是一个工具，而是你编程节奏的一部分。