之前博客是用坚果云在多设备之间同步整个工程目录的，这种方式有不少坑：

  • node_modules/ 体积大、文件数多，反复同步既慢又容易冲突
  • public/ 是构建产物，没必要同步
  • 没有版本历史，写错了想回滚只能靠记忆
  • 多设备并发修改时容易产生 .conflict 文件

迁移到 Git 之后这些问题全部消失。这篇文章把整套方案、每个设备首次配置、日常流程、冲突处理、应急方案都记下来，以后换电脑直接照着做。

整体架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
┌──────────────────┐         ┌────────────────────────┐
│ blog-source      │         │ YTALIEN.github.io      │
│ (Private repo)   │ ─────►  │ (Public repo)          │
│                  │ Actions │                        │
│ - 源码           │ 自动构建 │ - 仅 hexo generate 产物 │
│ - 主题           │ 自动部署 │ - GitHub Pages 公开访问  │
│ - 配置           │         │                        │
│ - 草稿           │         │                        │
└──────────────────┘         └────────────────────────┘
        ▲ ▼
        │ │ git pull / push
        │ │
┌──────────────────────────┐
│ 本地多设备：              │
│  - 台式机 D:\blog        │
│  - 笔记本 ~/blog         │
│  - 任何新设备            │
└──────────────────────────┘

两个仓库分工：

  • blog-source（私有）：保存所有源代码，包括草稿、配置、主题。push 到这里就会触发自动构建。
  • YTALIEN.github.io（公开）：仅保存 hexo generate 产生的静态站点（HTML/CSS/JS），所有访客看到的内容。

为什么用两个仓库而不是一个？
GitHub Free 账号下，私有仓库发布的 Pages 也是私有的（访客无法访问）。两库分离后，源码完全私密，部署的静态站公开访问，互不影响，也不依赖付费订阅。

一、新设备首次配置

假设你拿到一台新电脑，要在上面继续写博客。按下面顺序执行：

1. 装基础工具

工具 用途 下载地址
Git 版本控制 https://git-scm.com/
Node.js (LTS) Hexo 运行环境，选 v20 https://nodejs.org/
一个顺手的编辑器 写 Markdown VS Code 或别的

装完后在终端验证：

1
2
3
git --version       # 任意 2.x 版本
node --version      # v20.x 或更高
npm --version

2. 配 Git 身份

1
2
git config --global user.name "YTALIEN"
git config --global user.email "ytalienzhong@gmail.com"

3. Clone 仓库

选一个干净的位置（不要放在任何云盘同步目录里，避免和 Git 冲突）：

1
2
3
4
# Windows 示例
cd D:\
git clone https://github.com/YTALIEN/blog-source.git blog
cd blog

第一次 clone 会让你登录 GitHub。Windows 上一般会自动弹出 Git Credential Manager 让你浏览器登录，登一次就行，凭证会缓存。

4. 装依赖

1
npm install

需要 1-3 分钟，装完会出现 node_modules/ 目录（已在 .gitignore 里，不会被提交）。

5. 本地预览（可选）

1
npx hexo server

打开 http://localhost:4000 看博客本地效果。Ctrl+C 停止。

至此新设备配置完毕。

二、日常写作流程

写新文章

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 1. 拉最新（多设备协作必做，单设备也建议做）
git pull

# 2. 用 hexo 生成文章骨架（可选，也可以直接手动建文件）
npx hexo new "我的新文章标题"
# 生成在 source/_posts/我的新文章标题.md

# 3. 用编辑器写内容

# 4. 本地预览
npx hexo server

# 5. 提交并推送
git add -A
git commit -m "新增文章：我的新文章标题"
git push

git push 完成后，自动构建会在 1-2 分钟内启动，3-5 分钟内站点更新。

改主题或配置

和写文章一样的流程：改完文件 → git add → commit → push。

查看部署状态

构建过程：https://github.com/YTALIEN/blog-source/actions

打开后点最新一条 workflow run 可以看每一步的日志。

三、多设备协作的关键纪律

只要你在 A 设备 push 之后没回到 A 之前，就一定要在 B 设备先 git pull。简单原则：

每次坐下来写之前先 git pull，每次离开前确认 git push 完。

这条纪律遵守了，几乎不会遇到冲突。

如果忘了 pull 就开始写

不慌。两种情况：

情况 A：你改的文件和远程改的文件不重叠

1
2
3
git pull --rebase
# Git 会把你的本地 commit 接到远程之后，无冲突
git push

情况 B：改到同一个文件的同一处

1
2
git pull --rebase
# 报冲突，Git 会标出冲突文件

打开冲突文件，找到 <<<<<<< HEAD 和 >>>>>>> 之间的内容，手动选择保留哪一段、删掉冲突标记，然后：

1
2
3
git add <冲突文件>
git rebase --continue
git push

如果一时搞不定想放弃 rebase：

1
git rebase --abort   # 回到 pull 之前的状态

推荐配置：自动 rebase

避免每次 pull 多出一个莫名其妙的 merge commit：

1
git config --global pull.rebase true

设了之后 git pull 默认 --rebase，提交历史会保持线性。

四、应急场景手册

想看某篇文章的历史改动

1
2
git log --oneline -- source/_posts/某文章.md
git diff <旧commit> <新commit> -- source/_posts/某文章.md

误删了文件还没 commit

1
git checkout -- <文件路径>

误删了文件已经 commit

1
2
git log --all --diff-filter=D --summary | grep <文件名>   # 找出删除的 commit
git checkout <删除前的commit>^ -- <文件路径>              # 恢复文件

想回滚整个站点到某个历史版本

1
2
3
git log --oneline                  # 找到目标 commit hash
git revert <hash>                  # 生成一个反向 commit
git push                           # 自动触发新一轮构建，站点回滚

revert 比 reset --hard 安全：它不是擦掉历史，而是追加一个"撤销"提交，可以再 revert 回去。

Actions 构建失败了

  1. 打开 https://github.com/YTALIEN/blog-source/actions
  2. 点失败那条 run
  3. 看红叉的那一步日志

常见原因：

  • npm ci 失败：通常是某个依赖版本对不上。本地 npm install 后把新的 package-lock.json 提交进去。
  • hexo generate 失败：本地先跑 npx hexo clean && npx hexo generate 复现错误，看是哪篇文章的 markdown 或 front matter 出问题。
  • Deploy 那一步报 401/403：DEPLOY_TOKEN 过期了或权限被改。重新生成 PAT 并更新 Secret。

PAT 即将过期或被泄露

  1. 删旧 token：https://github.com/settings/tokens
  2. 按 创建 PAT 步骤 重新生成
  3. 在 blog-source 仓库 → Settings → Secrets → 更新 DEPLOY_TOKEN

旧 token 一旦删除立即失效，未来的构建会用新 token，不需要其它改动。

五、避坑清单

  • 不要把仓库放在 OneDrive / 坚果云 / Dropbox 同步目录里。 Git 自身就是同步工具，叠加云盘只会让 .git/ 目录损坏。
  • 不要手动 commit node_modules/、public/、db.json。 .gitignore 已经排除它们；如果不小心提了，用 git rm -r --cached <目录> 移出版本控制再 commit。
  • 不要在公开仓库写 PAT、API key、密码。 即便后来删了，Git 历史里依然能找到，应当作已泄露处理，立刻轮换。
  • 新设备 clone 完别忘了 npm install。 不装依赖直接 hexo server 会一堆报错。
  • hexo clean 偶尔救命。 本地预览出现幽灵旧内容时，跑一次 npx hexo clean 清掉缓存再生成。

总结

从坚果云迁移到 Git + GitHub Actions 后，多设备同步的痛点基本被消灭：

  • 同步只传源文件（几 MB），不传 node_modules（几百 MB）
  • 完整版本历史，任何错误都能回滚
  • 写完即自动部署，不再手动 hexo deploy
  • 草稿和配置仍然私密
  • 新设备一次 git clone 就能继续工作

唯一需要的纪律是：写之前 git pull，写完 git push。

以后再也不用看到坚果云目录里出现 xxx.md.conflict 了。