不懂 GitHub，也能让 AI 帮你备份本地 Obsidian 知识库

Su8082 曝光 · 30 收藏
Obsidian Vault、普通文件夹、Git 仓库和 GitHub 远端，到底是什么关系？

这篇文章来自我整理个人OS系统 my-OS 的一次真实操作。

个人OS代表底层思维模式、价值观、本能反应、行事逻辑。

我先把整套 my-OS 放进一个独立文件夹，再把它打开为 Obsidian Vault，最后让 Codex 接入 Private GitHub，保留版本记录和远端副本。

事实上，Obsidian Vault 在技术底层仍然是一个本地文件夹。

因此，这套方法不只适用于 Obsidian。普通资料文件夹、本地项目目录，只要适合用 Git 管理，也可以用相同的底层方式连接 GitHub。

（感兴趣又懒得读人群 👉 Part3 看不懂时把文章交给AI（含提示词）

这篇文章适合谁？

  • 对AI感兴趣、入门、正在搭建自己的知识库，可以把这篇文章，投喂给AI做知识库。关于本地文件如何完成远端备份。
  • 已经成为或准备成为的 AI Builder，开始制作应用、脚本、Agent 或自动化工作流；
  • Obsidian 里已经积累了重要笔记、知识库或个人系统；
  • 本地已经有代码项目、脚本、自动化流程或完整文件夹形态的工程；
  • 工作中需要管理方案、内容、设计稿或交付文件的多个版本；
  • 担心 AI 批量修改后无法恢复，想给重要文件建立一份持续、可检查的版本副本。

除了 AI 用户，设计师、内容创作者和研究者也可以使用这套思路来给自己的内容进行备份，需要注意的点是：如果文件类型是文案、Markdown、SVG、设计规范和配置文件很适合 Git；而大型 PSD、AI 或视频工程则不能直接照搬，后文会说明边界。

这篇文章真正要解决的是：当本地文件已经重要到不能只靠“它还在电脑里”，怎样让 AI 帮你把版本记录和私密远端接起来。

这篇文章能带走什么？

即使不会 Git 命令，也可以让 AI 帮你完成：

找到重要的本地文件夹 → 检查是否适合 Git 管理 → 建立本地版本记录 → 连接 Private GitHub → 完成一次真实修改和远端验证

最后你将得到的是：

  • 一份本地唯一正式内容；
  • 可检查、可回退的修改历史；
  • 一份已经提交到 Private GitHub 的远端版本；
  • 一条以后可以交给 Codex 维护的路径。

这里说的“GitHub 备份”，更准确地说是私密远端版本副本。

没有执行 `commit` 和 `push` 的修改，不会自动出现在 GitHub。它也不能完全替代 Time Machine、网盘或 Obsidian Sync。

看不懂时，先把文章交给 AI

这段提示词只负责帮你看懂文章、判断是否适合，不会直接修改文件或创建仓库。

请阅读这篇文章。 我的目标不是系统学习 Git，而是判断： 我的本地 Obsidian Vault 或重要项目文件夹【可以把文件夹作为reference或者把根目录贴进来】，是否适合连接 Private GitHub，建立一份可验证的远端版本副本。 先不要修改文件、创建仓库或执行命令。 请告诉我： 1. 这篇文章最终能帮我得到什么； 2. 哪些概念现在必须懂，哪些可以暂时跳过； 3. 根据我的情况，00—05 应该重点看哪几段； 4. 执行前必须确认哪些目录、隐私和 Git 状态； 5. 适合我的最短路径是什么； 6. 是否已经适合交给 Codex 执行。 信息不足时，只问真正影响方案的问题。

阅读指引

👉 有重要 Obsidian Vault 或长期项目，但完全不懂 GitHub：看 `00`。

👉 想知道普通文件夹和 Obsidian Vault 有什么区别：看 `01`。

👉 被“Vault、Repo、Remote、Origin”绕晕：看 `02—03`。

👉 已连接 GitHub，想确认是否真的备份成功：看 `04`。

👉 想知道能不能自动备份、是不是联网就会执行：看 `05`。

👉 想让 Codex 直接完成：先看 `00` 的边界，再复制文末提示词。

00｜什么时候值得做？

适合这一部分的人：

  • Obsidian 里已经积累了不能轻易丢失的笔记；
  • 某个 Vault 已经成为长期知识库；
  • 有产品、内容、研究或个人系统以完整文件夹形式维护；
  • 有些项目本来就以仓库形式放在本地；
  • 经常让 AI 批量修改文件，担心改坏后无法恢复；
  • 换电脑时，希望能重新取得一份完整版本。

判断标准不是“我用了 Obsidian，所以必须接 GitHub”。

而是：

这个文件夹是否已经重要到，需要知道它改过什么、能退回哪一版，并在本机之外保留一份版本副本？

如果答案是“是”，就值得考虑。

⚠️以下内容不要直接上传：

  • API Key、Token 和密码；
  • 客户原始资料；
  • 身份证、住址和联系方式；
  • 未脱敏的家庭隐私；
  • 临时缓存、测试文件和大型媒体；
  • 自己也无法判断能否交给第三方托管的资料。

Private 不等于可以不检查。

01｜Obsidian Vault 和普通文件夹，有什么区别？

先说结论：从 Git 的角度看，没有本质区别。

Obsidian 官方对 Vault 的定义，本来就是本地文件系统中的一个文件夹。已有文件夹也可以直接使用“Open folder as vault”打开。Obsidian 官方说明

例如我的 my-OS：

Documents/ └── Obsidian/ └── my-OS/ ├── README.md ├── Reference/ ├── Decision-Log/ └── Prompt-Library/

它同时有三个身份：

对 macOS：一个普通本地文件夹 对 Obsidian：一个独立 Vault 对 Git：一个可以记录版本的 Git 仓库

同一个文件夹用 Obsidian 打开后，就成为一个可以阅读、搜索和建立双向链接的 Vault。

普通文件夹接 GitHub，底层路径完全一样：

普通文件夹 → 初始化 Git → 连接远端 → commit → push

真正的差异在内容和规则：

  • Obsidian Vault 常见 Markdown、附件和 `.obsidian` 本地配置；
  • 软件项目常见代码、配置、构建产物和依赖；
  • 普通资料文件夹可能包含 Word、PDF、图片和大型文件。

因此它们都能使用 Git，但 `.gitignore`、敏感信息检查和文件大小策略不能照抄。

真正决定“是本地Vault还是要放进 Obsidian”的，不是 GitHub，而是这个文件夹平时主要拿来做什么：

  • 以阅读、写作、搜索和双向链接为主： 适合打开为 Obsidian Vault，再用 Git 保存版本。比如个人知识库、研究资料、Prompt Library、Decision Log，以及我的 my-OS。
  • 以运行、构建、测试和部署为主： 更适合保留为普通本地项目文件夹，直接作为 Git 仓库管理。比如代码项目、脚本、自动化流程和带大量依赖的工程。
  • 知识和工程混在一起： 按主要动作决定归属。代码和运行配置留在项目仓库；需要长期阅读和复用的判断、索引或总结放进 Obsidian，并通过链接指回项目，不复制两份正文。

所以虽然这篇文章是基于 Obsidian 和 Github 连接写的，但是并不是所有 Git 仓库都需要成为 Obsidian Vault，也不是所有 Vault 都必须接 GitHub。先看主要用途，再决定是否叠加另一层能力。

02｜为什么“仓库”这个词特别容易混淆？

中文界面里，Obsidian Vault 有时被翻译成“仓库”；Git Repository 也叫“仓库”。

它们不是一回事：

  • `Obsidian Vault`：Obsidian 认识并打开的本地文件夹；
  • `Git 仓库`：Git 开始记录修改历史的文件夹；
  • `GitHub Repo`：这套 Git 历史在 GitHub 上的远端仓库。

⚠️一个 Vault 不会因为被 Obsidian 打开，就自动拥有 Git 历史。

普通文件夹也不会天然成为 Git 仓库。它们都需要先初始化 Git。

初始化后，Git 会记录：

  • 哪些文件变了；
  • 具体改了什么；
  • 哪一次是稳定版本；
  • 改坏后可以回到哪里。

但初始化前必须检查：目标文件夹或它的上层目录，是否已经属于另一个 Git 仓库。否则可能形成新手难以维护的嵌套仓库。

03｜Remote 和 Origin 到底是什么？

本地初始化 Git 后，版本历史仍只在这台电脑上。

想把它送到 GitHub，需要一个远端地址：

origin → https://github.com/用户名/仓库名.git
  • `Remote`：远端仓库地址；
  • `origin`：这个地址最常用的简称；
  • `commit`：在本地保存一次版本快照；
  • `push`：把本地快照发送到 GitHub；
  • `pull`：把 GitHub 上的新版本取回本地；
  • `clone`：在另一处下载包含历史记录的完整仓库。

正确关系是：

同一个本地文件夹 ├── Obsidian 或其他软件负责编辑 ├── Git 负责记录历史 └── origin 指向 Private GitHub Repo

日常编辑的仍是本地文件，GitHub 保存的是已经提交并推送的版本。

是需要你主动 Commit 并 Push 到远端，所以GitHub的这个备份，它并不会实时自动备份，不会因为你在文件夹里本身的任意一个动作，它就主动快速地进行备份。 简单来说，Commit并Push可以理解为将当前的文件夹快照后推到GitHub远端。

04｜怎样才算真的备份成功？

判断标准只有一句：

假设现在换了一台电脑，我还能不能从 GitHub 把这套内容完整拿回来？

所以第一次完成 commit 和 push 后，最好做一次恢复测试：

  • 在 GitHub 确认刚修改的文件已经出现；
  • 把远端仓库重新 clone 到一个临时文件夹；
  • 用 Obsidian 打开这个新文件夹，或直接检查普通项目；
  • 确认重要文件、目录结构和内部链接都能正常使用。

同时确认仓库仍是 Private，密钥、缓存和临时文件没有被上传。

只有重新下载后仍然能用，才说明 GitHub 保存的不是空仓库或残缺版本。

05｜它会自动备份吗？联网就会执行吗？

不会。

联网是 push 成功的必要条件，但不是自动备份的触发器。

GitHub 不会因为发现电脑联网，就主动扫描本地文件夹。

完整过程需要有人或某个自动化执行：

检测文件变化 → git add → git commit → git push

其中：

  • 没联网时，本地仍然可以创建 commit；
  • 只有 push 需要连接 GitHub；
  • 联网后不会自动 push，除非提前配置了定时或事件触发；
  • 自动任务离线执行时，push 通常会失败，需要下一次任务再重试。

可以分三层：

第一层：手动交给 Codex，最适合新手

修改完成后告诉 Codex：

检查本次修改，确认没有敏感信息后，创建 commit 并推送到现有 Private GitHub Repo。

优点是每次提交前都能看见变化，不容易把隐私和错误一起自动上传。

第二层：定时自动提交

可以使用 Obsidian Git 插件、系统定时任务或其他自动化工具，按时间检查变化并执行 commit、push。

但应该先手动跑通，再自动化。还要明确：

  • 多久执行一次；
  • 提交说明怎么生成；
  • 离线失败后怎么重试；
  • 多设备修改冲突时由谁处理；
  • 哪些内容永远不能提交。

第三层：多设备维护

多台电脑编辑同一仓库时，要增加：

开始前先 pull → 完成后 commit + push

否则两台设备同时修改，可能产生冲突。

不要同时配置多个自动化工具管理同一个仓库。Obsidian Git 插件、系统定时任务和其他自动流程如果一起提交，反而更容易制造重复 commit 和冲突。

准备好了，再交给 Codex 执行

前面的提示词用于理解和判断；下面这段才是让 Codex 实际检查、连接并验证备份。

请把下面这个本地文件夹作为唯一正式内容源： [填写绝对路径] 它可能是 Obsidian Vault，也可能是普通项目或资料文件夹。 目标： 把它安全地接入一个 Private GitHub 远端仓库，并完成一次可验证的版本备份闭环。 执行前先只读检查： 1. 目标文件夹是否存在； 2. 目标文件夹及上层目录是否已有 Git； 3. 是否会形成错误的嵌套仓库； 4. 是否已有合适的 GitHub Repo； 5. .gitignore 是否符合当前文件类型； 6. 是否包含密钥、客户资料、家庭隐私或临时文件； 7. GitHub Repo 是否确定为 Private。 如果需要创建远端，或仓库名称、账号归属不明确，请集中问我一次。 获得授权后： 1. 初始化或接入本地 Git； 2. 将远端命名为 origin； 3. 创建第一次 commit； 4. 推送到 main； 5. 验证仓库为 Private； 6. 确认本地 HEAD 与 origin/main 一致； 7. 从远端重新 clone 到临时目录； 8. 检查文件、目录和相对链接； 9. 清理临时验证文件。 完成后返回： - 唯一本地正式位置； - GitHub 仓库地址与 Private 状态； - commit ID； - 本地与远端一致性证据； - clone 验证结果； - 未来适合手动维护还是自动维护。

最后只需要记住：

Vault 是 Obsidian 认识的本地文件夹。 普通文件夹和 Vault 都可以成为 Git 仓库。 Remote 是本地 Git 连接 GitHub 的地址。 联网不会自动备份，触发器才会。

先跑通一次真实闭环，再决定要不要自动化。