编辑器开始懂 Git：改动、提交图和 worktree
砚最初只打算做少量 Git 标记，更复杂的操作留给命令行。随着 Mayoi 的能力进入项目，Git 成了工作台里一个实际可用的部分。
这条线分两步长起来：先知道“文件改了什么”，再知道“这些改动处于怎样的提交历史里”。
先把工作区变化看清楚
最早接进来的 Git 能力包括资源管理器状态、代码行旁的增删改标记、当前行 blame、暂存与取消暂存、提交、推送拉取、分支切换，以及改动视图。
底层主要通过 Git CLI 取得结果。行 diff 和词级 diff 再转成界面需要的数据。查看改动时，折叠不相关的行，回车或双击可以跳到文件对应位置。
这里有个必须说清的区别：已跟踪文件的丢弃修改，与未跟踪文件移到回收站，恢复方式并不相同。不能把界面上同一个“丢弃”概念，都宣传成“去回收站就能找回”。
此外，提交前可能需要保存缓冲区。上一篇提到的磁盘冲突保护，因此也必须覆盖 Git 操作前的保存路径。
到 alpha.3，提交历史变得可见
第三个预览版增加了最近 200 个提交的历史图。分支用轨道和颜色区分，分支名与标签作为标记，HEAD、合并提交、尚未推送的提交也有对应提示。
点击一个提交，可以看它改过的文件、复制提交号、检出，或者从那里创建分支、标签。
对编辑器来说，这让“我看到这行为什么变了”到“去看对应提交”之间少了一次工具切换。实现上，图的排布逻辑在内核，终端版用近似线条展示，GUI 再绘成更完整的图形。
但现在的历史仍然是一次读取最近 200 个提交。没有把“能展示提交图”写成已经具备完整的无限历史浏览能力。
切分支还要看 worktree
使用 worktree 后，一个分支可能已经在另一个目录检出。编辑器如果仍然只执行普通 checkout，用户看到的往往就是 Git 的报错。
砚在这个场景里先找占用该分支的 worktree。如果目录存在，提供在当前窗口打开那个工作区的选择；如果目录已经被删除，提供清理对应失效记录后再切换的入口。
这里“对应”两个字很重要。为了切这一个分支，不应该顺便清理其他失效 worktree。alpha.3 的测试记录专门覆盖了这个边界。
对我来说，这是一种挺典型的工具交互：Git 语义仍然是 Git 的，界面要把用户下一步能做的事解释出来。
同一版还补了几处手感
alpha.3 除了 Git，也加入了排序行、驼峰转换、制表符或 2/4/8 空格缩进选择，要求覆盖多光标。
触控板滚动则按手势主方向处理，避免竖向滚动时横向漂移，并保留慢速横划的位移。图标也换成了文本光标滴下一滴朱红墨水的形象。
我把这些放在同一段记录里，是因为它们反映出项目阶段的变化：开始有足够完整的工作流之后，交互细节和识别度也值得认真补。
历史记录里的“通过”有范围
alpha.3 说明记载了真实临时 Git 仓库上的自动化测试，以及安装后的应用启动与退出检查。它也明确说明，没有逐项在真实窗口中手工点过提交图、编辑菜单和触控板滚动。
所以这里记录的是功能进入版本、相关自动化已覆盖。真实手感仍然要靠实际使用继续验证。
后面 alpha.4 又补进了 merge、rebase、reset 等操作。那部分状态更复杂，留到文件工作流那篇一起讲。
