更新于 2026 年 8 月 23 日
同步你的 vault
vault 就是一个装着 Markdown 文件的文件夹，没有任何私有格式，所以把它弄到第二台设备上的合理办法不止一种。Inkstone 提供两种，各有各的长处。
| iCloud Drive | GitHub | |
|---|---|---|
| 设置 | 把文件夹放进 iCloud Drive | 一个仓库和一个访问令牌 |
| 速度 | 几秒 | 几分钟，按计划执行 |
| 历史 | 无法翻阅 | 每一次改动都是一个提交 |
| 适用于 | 你自己的 Apple 设备 | 任何能访问 GitHub 的东西 |
| 成本 | iCloud 存储空间 | 私有仓库免费 |
两者并不互斥。一个 vault 可以既放在 iCloud Drive 里，又推送到 GitHub——iCloud 在你自己的设备之间搬得快，GitHub 保留历史和一份不依赖 Apple 的副本。
iCloud Drive
没有开关要打开。把 vault 文件夹放进 iCloud Drive 再打开它，剩下的 iCloud 会做——搬文件的是系统，不是 Inkstone。
唯一存在的设置是保持文件已下载，默认开启。iCloud 会把你最近没打开过的文件内容清掉以节省磁盘，只留一个占位符。而占位符在 Inkstone 看来就是一篇空笔记，所以一个闲置了一阵的 vault 会看起来像丢了笔记。只在磁盘真的紧张的机器上才关掉它。
iCloud 会产生它自己的冲突副本。如果同一个文件在两台设备上都被改过、而两边都还没同步完，iCloud 会两份都留下并标记其中一份。那是 Apple 的机制，不是 Inkstone 的，长得也和下面说的不一样。
GitHub
你需要一个仓库——私有的完全可以，而且很正常——以及一个细粒度个人访问令牌，对该仓库拥有 Contents: read and write 权限。令牌存在你的钥匙串里，绝不写进 vault，也绝不写进设置文件。
第一台设备
- 打开你想同步的 vault。
- 设置 › Sync，打开 Sync this vault with GitHub。
- 粘贴令牌，选择仓库和分支。
- 点 Sync now。
第二台设备
从一个空文件夹开始。这一条比本页其他任何内容都重要。
- 新建一个空文件夹，把它作为 vault 打开。
- 填入同一个仓库和分支。
- 同步。它会问你哪一边算数——选 Keep GitHub's。
把一个已经装着笔记的文件夹指向一个装着另一批笔记的仓库，等于要求两套不相干的文件合成一套。App 无法知道哪个是哪个，于是两份都留下，每一个有差异的文件你都会得到一份冲突副本。
仓库属于 vault，不属于 App。每个 vault 有自己的仓库设置。打开另一个 vault 不会继承上一个的，而没有被指定仓库的 vault 根本不会同步。
一个仓库，一台设备上只能有一个 vault
同一台设备上，两个文件夹不能同时绑定同一个仓库。Inkstone 会拒绝，并且在其中一个放弃之前，两个都不会同步。
这不是限制，而是一种没有正确行为可言的配置：每次同步都会把仓库改造成最后跑的那个文件夹的样子，于是两者轮流覆盖对方。再聪明的算法也救不了它——没有任何办法判断两个工作副本里哪一个才是仓库该有的样子。
面板会指出是哪个 vault 已经占着它，并提供「改绑到这个 vault」，而不是简单拒绝：绑定的寿命会超过当初那个文件夹，一堵没有门的墙会让你在任何地方都用不了那个仓库。
两台设备共用一个仓库正是这个功能的意义所在，完全不受影响。
冲突什么时候发生
只有一种情况会产生冲突：
同一个文件，自两边上次达成一致以来，在两台设备上都被改过。
规则就这一条。每次同步会为每个文件比较三样东西：这里是什么、GitHub 上是什么、以及上一次完成的同步记录了什么。如果只有一边动了，那一边胜出，毫无歧义。如果两边都动了，就没有任何 App 能替你选的答案。
也就是说：
- 在一台上改、等它同步完、再用另一台——永远不冲突，隔多久都一样。
- 在两台设备上改不同的笔记——永远不冲突，哪怕一边很旧。
- 在同步之前，两台设备上改同一篇笔记——会冲突，也应该冲突。
冲突绝不覆盖任何东西。GitHub 那一份会写在你这份旁边，名字是 笔记 (conflict 2026-08-23 1420).md，两份都在。打开它们，留下你要的，删掉另一份。副本只生成一次，不是每次同步生成一次。
首次同步是例外
首次同步之前，没有任何「两边曾经一致」的记录，所以每一个两边都存在且有差异的文件都像是「都改过」。它不会为每个文件都造一份冲突副本，而是问你一次——留本机的、留 GitHub 的、还是两个都留——然后记住这个答案。
怎么少遇到冲突
- 换设备之前先同步。在 iOS 上，同步会在你离开 App 之后继续跑，系统会一直显示进度直到跑完。
- 在手机上编辑之前，先让它把同步跑完。Sync 面板在工作时会显示进度条和文件计数。
它实际多久跑一次
你选的间隔是下限，不是承诺。
在 macOS 上 App 一直在运行，所以间隔是准的。在 iOS 上由系统决定：它根据你打开 App 的频率来分配后台时间，而且如果你从多任务卡片里划掉了 App，在你再次打开它之前系统不会唤醒它。预期是一天几次后台运行，而不是每个间隔一次。「后台 App 刷新」必须开启，低电量模式会完全暂停它。
设置 › Sync 会显示系统实际做了什么——上次唤醒 App 是什么时候，以及每一次尝试的记录。
如果这个 vault 是 git 工作树
如果文件夹里有 .git 目录，Inkstone 的 GitHub 同步会自动关闭，并说明原因。
这不是限制，而是两套机制在打架。git 会合并：三方合并、有历史、冲突标记由人来解决。Inkstone 的同步是逐文件、后写覆盖先写。让两者在同一个文件夹上跑，各自会撤销对方的结果。
行得通的安排是每套机制只有一个写入方：
桌面端用 git，手机端用 Inkstone。手机的改动通过 git pull 到达桌面；桌面的改动推送之后到达手机。提交之前先 pull——手机也在往同一个分支写。
如果你确实想同步一个 git 工作树，有一个针对单个 vault 的覆盖开关。不主动打开它就一直是关的。
Inkstone 拒绝做的事
有几种情况看起来像是一条指令，但几乎总是意外，所以同步会停下来而不是照做。
- 仓库变空了，但之前在那里记录过文件。空列表远远更可能是分支填错了或令牌掉了权限，而不是有人真的清空了它——而对「远端文件被删」的正确反应是删掉本地那份。
- 分支不存在。报错会列出实际存在的分支。
- 这个 vault 是 git 工作树，见上。
被打断的同步是安全的：已经搬过去的会保留，下一次从那里继续，而不是重头再来。
哪些文件会被同步
笔记和白板永远同步。附件按类型同步——图片、音频、PDF、视频、其他文件——每一类有自己的开关，另有一个体积上限。都在设置 › Sync 里。
vault 根目录下的 .gitignore 会被遵守，并且会跟着 vault 一起同步，所以第二台设备拿到的是同一套规则，而不是把第一台刻意排除掉的东西全都传上去。