内置 Git
Restorm 项目天生就是为了存放在一个 git 仓库里。这项集成比单纯的
git commit 走得更远：它理解项目文件的格式，能在业务实体这一层解决冲突，
而不是在 YAML 的行这一层。
没有任何东西需要配置。只要打开的 .restorm 文件位于一个 git 仓库内，
相关的 git 界面就会自动启用。
Restorm 使用的是您本机的 git：不需要输入任何凭据，
应用里也不管理任何令牌。规则很简单 —— 如果 git push
在您的终端里能用，它在 Restorm 里也能用。Git 是在禁用交互提示的模式下启动的：
一个会索要密码的仓库会立即带着 git 自己的错误信息失败，而不会把界面卡住。
状态栏中的 GIT 单元
Section titled “状态栏中的 GIT 单元”两个按钮，推送和拉取；当有内容待发送、或者远端存在更新版本时， 按钮上会出现一个小圆点（只是一个点，从不显示数字）。
标题栏中的 Git 菜单提供同样的操作，另外还有刷新、 重置为服务器版本和历史记录。
推送对话框会显示一条已经写好的提交信息，它是从结构化差异中 确定性地生成的 —— 完全不经过语言模型。每一个被修改的实体 （请求、场景、文件夹、变量文件夹）占一行，绝不会每个字段一行。
- 一个用于选择提交信息语言的选择器，与界面语言相互独立， 并带有一个可把它设为默认值的开关。
- 一个可编辑的标题，附带一个 72 字符的参考计数器。
- 一个多行的正文。
确认后会依次执行：保存、git add、提交、推送。
Restorm 会先保存，然后再拉取并合并。
干净合并：树结构和已打开的标签页会就地刷新。
发生冲突：会打开一个四面板的冲突解决视图。
| 面板 | 内容 |
|---|---|
| 冲突列表 | 处于冲突状态的实体 |
| 您的版本 | 只读 |
| 他们的版本 | 只读 |
| 已解决 | 可编辑 —— 这才是最终会被写入的内容 |
关键之处在于：每个面板都会用该实体真正的编辑器来显示它 ——
HTTP 请求用 HTTP 编辑器，场景用场景编辑器。您要做的不是在 YAML 里处理
<<<<<<< 标记，而是对比两个请求。
每一侧都有一个**“使用这个版本”按钮，而且存在分歧的字段会用红色高亮** —— 当只有一个字段不同时，面板会直接定位到相关的那个标签。
变量文件夹的 API 文档会自动解决冲突（较新的版本胜出）。
取消会执行一次 git merge --abort。如果您在解决冲突的过程中关闭了应用，
下次启动时 Restorm 会询问您是否放弃这次合并。
后台检查（semi-pull）
Section titled “后台检查（semi-pull）”Restorm 会定期检查是否存在更新的版本 —— 但绝不会自行合并。
共有三个触发条件：观察到 .git 发生变化、打开一个文件，
以及一个定时器（频率在设置 ▸ Git 中设定：关闭、15 分钟、30 分钟、
1 小时、4 小时、12 小时、24 小时）。
此时会出现一条“有可用更新”的通知，并提供 Pull now 操作。
文件被外部修改
Section titled “文件被外部修改”如果文件自打开以来在磁盘上发生了变化，保存操作会被拒绝， Restorm 会询问您是要重新加载还是保留您的版本。
为什么差异是可读的
Section titled “为什么差异是可读的”这来自格式的两项特性，详见
项目与 .restorm 文件：
一套规范化的键顺序，以及以稳定方式派生的标识符。
结果就是：打开后不做任何修改再保存，不会产生任何差异； 两个人在同一位置添加同一个请求，产生的实体也能被合并逻辑正确配对。
Git ▸ 历史记录会打开一个双栏视图：左侧是带分支线的提交列表， 右侧是详情。在某个提交上打开右键菜单，即可取回那个版本。
通过 MCP
Section titled “通过 MCP”共四个工具，需要 Pro 版：git_commit_push（两步中的第一步 ——
返回一个审阅令牌、标题、正文以及按实体划分的差异，但不写入任何东西）、
git_confirm_push（两步中的第二步 —— 如果项目在审阅之后发生了变化则会被拒绝）、
git_pull 和 git_resolve_conflicts。
拆成两步是有意的设计：智能体不可能在没有先呈现差异的情况下完成推送。