Obsidian 同步、版本控制与发布架构

区分 Obsidian Vault 的多设备同步、版本历史/备份、公开发布和站点部署四个不同问题，并把 Git、同步服务、Quartz 与 Digital Garden 放回各自职责。

#obsidian #synthesis #evergreen

[!info] related notes

所属 MOC: Obsidian MOC

Git 操作: Obsidian Git 插件指南

静态发布选型: Obsidian 静态发布方案选择

Digital Garden: Obsidian Digital Garden 插件指南

Quartz: Quartz 静态部署指南

写作: Obsidian 写作工作流

Obsidian 同步、版本控制与发布架构

一句话关系

Obsidian 工作流里最容易混在一起的四件事是：

Sync
≠ Version History / Backup
≠ Publish
≠ Hosting / Deployment

它们可以用同一个 Git 仓库串起来，也可以完全使用不同系统。

第一层：Vault Source of Truth

真正编辑的 Markdown Vault 是源数据。

Vault
├─ Markdown
├─ assets
├─ frontmatter
├─ wikilinks
└─ .obsidian configuration

所有同步、Git、发布系统都应该围绕 Vault 服务，而不是反过来让某个网站构建产物成为新的主数据。

第二层：多设备同步

同步回答：

设备 A 改完文件后，设备 B 怎样得到同一份最新文件？

可以由：

专用同步服务；
文件同步/云盘；
Git pull/push；
其他 replication 工具；

承担。

同步关注：

冲突；
离线修改；
大文件；
延迟；
多端可用性。

它不自动等于可靠备份。

第三层：版本控制与备份

版本控制回答：

某次错误修改之后，能否知道发生了什么并恢复？

Git 很适合 Markdown Vault：

working tree
→ commit history
→ remote copy

但：

Git remote 不是完整灾备；
自动 commit 不等于零冲突；
二进制大文件要单独设计；
多设备同时编辑仍可能产生 merge conflict。

具体操作统一看 Obsidian Git 插件指南。

第四层：公开发布

发布回答：

Vault 中哪些内容应该成为别人可以访问的站点内容？

这是一个 projection 问题：

Private Vault
→ selection / transform
→ public content

最重要的边界是：

私有 Vault 不应该因为“同步方便”就自动等于全部公开。

发布层需要明确：

public/private selection；
frontmatter；
wikilink 转换；
attachment handling；
draft；
secret scanning。

第五层：构建与 Hosting

如果使用静态站点：

Markdown
→ static-site build
→ HTML/CSS/JS
→ hosting/CDN

Quartz、MkDocs 等位于 build/publishing pipeline。

GitHub Pages、Cloudflare Pages、Vercel 或自己的 Web Server 则更接近 deployment/hosting。

“用 GitHub”本身不能说明你是在：

同步；
备份；
CI build；
hosting；

哪一层。

为什么旧的“完整方案 / 简化方案 / 企业方案”不稳

把方案直接命名成：

新手方案
专业方案
企业方案

很容易过期。

更稳定的选择方式是先看需求矩阵：

需求	主要问题
两台电脑编辑同一 Vault	Sync
恢复昨天误删的段落	Version history
云端再保留一份副本	Backup
公开部分知识笔记	Publish
自定义知识站 UI	Static build
自定义域名/HTTPS/CDN	Hosting

然后分别选工具。

三种常见组合

组合 A：只同步，不公开

Vault
→ sync
→ other devices

适合纯私人知识库。

无需为了“看起来完整”再加 Quartz 或 Digital Garden。

组合 B：Git 同步/版本 + 静态发布

Vault
→ Git
→ CI
→ Quartz/MkDocs build
→ hosting

优势是 Markdown 与版本历史清楚。

代价是：

merge conflict；
CI/build 维护；
public/private filter 要明确。

组合 C：私人同步 + 独立发布投影

Vault
├─ private sync
└─ selected public notes
    → publish pipeline

这是比较清晰的隐私边界：

同步全库与发布部分内容使用不同控制面。

多设备冲突模型

Git 类同步最常见错误是：

Device A edit
Device B edit
A push
B push without pulling
→ conflict / rejected push

更稳的纪律：

pull/reconcile
→ edit
→ commit
→ push

自动化可以减少操作，但不能消除并发写入语义。

发布流水线最小模型

Authoring Vault
→ public selection
→ build validation
→ generated site
→ deploy
→ smoke check

如果 build 失败，应该修源内容或构建规则，而不是手工修改 generated HTML。

选择检查表

开始配置前回答：

常见误区

Sync = Backup

错误。

同步系统可能把“误删”同样快速同步到其他设备。

Git = 实时同步

Git 是版本控制模型，可以被用来同步，但天然不是实时 collaborative filesystem。

Publish = Sync

Digital Garden / static publish 面向阅读者，不应承担多设备编辑的一致性。

网站仓库 = Vault

如果构建产物和源 Markdown 混在一起，后续很容易出现双向漂移。

学习检查

不看正文回答：

Sync、Version History、Backup、Publish、Hosting 分别解决什么？
为什么一个 GitHub 仓库可能同时参与多个层，但这些层仍不能混为一谈？
为什么同步不等于备份？
私有 Vault 全量同步与公开部分笔记之间应该怎样建立边界？
Static generator 与 hosting provider 为什么不是同一个对象？
给一个“Windows + 手机编辑，部分笔记公开”的场景，画出 source、sync、version、publish、hosting 五层。
如果网站构建失败，为什么不应该直接编辑生成后的 HTML？