Obsidian 到 GitHub 再到 Cloudflare：把技術筆記變成自動發布流程

2026/09/15

如果平常已經使用 Obsidian 寫筆記，最理想的狀態是不需要另外打開 CMS。

可以把流程設計成：

Obsidian
   ↓
Vault Git repo
   ↓
GitHub Actions
   ↓
獨立 Blog repo
   ↓
Cloudflare

為什麼 Blog 要獨立 repo

主 Vault 可能同時包含工作筆記、專案資料、草稿與 Blog，但 Cloudflare 不應直接拿整個 Vault build。

所以保留兩個 repo：

Vault repo
= 所有 Obsidian 筆記

Blog repo
= Astro 網站

GitHub Actions 負責中間分流。

blog/
├── drafts/
└── published/
    ├── 2024/
    ├── 2025/
    └── 2026/

規則：

drafts/
= 還沒發布

published/
= 網站應該存在的全部文章

網站 repo 的：

src/content/blog/

可以完全由：

blog/published/

鏡像：

rsync -av --delete   blog/published/   blog-repo/src/content/blog/

這時 --delete 才安全，因為 published/ 已經代表正式網站的完整內容。

只在 Blog 內容有變化時觸發：

on:
  push:
    branches:
      - main
    paths:
      - "blog/published/**"

這樣一般筆記更新不會觸發網站 deployment。

Workflow 需要讀 Vault repo、寫 Blog repo，因此需要一個只允許寫 Blog repo 的 credential。

權限遵循最小權限即可，例如：

Contents: Read and write

概念上只有：

Checkout Vault repo
Checkout Blog repo
rsync published/
commit + push Blog repo

Blog repo 一更新：

GitHub Actions
      ↓
Blog repo
      ↓
Cloudflare
      ↓
Astro build
      ↓
正式網站

如果 blog/published/ 裡的文章被刪掉，下次 Action 的 rsync --delete 會讓 Blog repo 同步刪除。

Cloudflare 下一次 build 後，該文章網址就會變成 404。

Obsidian 負責寫作與整理，GitHub 負責版本控制與 Automation，Astro 負責產生網站，Cloudflare 負責 build 與 hosting。

每一層只做一件事，整體會比同一個資料夾同時使用多套同步機制更容易維護。