博客相关知识

1.在 Hexo 中，每篇博客文章的开头需要包含一个 YAML 头部（Front-matter），用于定义文章的元数据（如标题、日期、分类等）。

1
2
3
4
5
6
7
---
title: 文章标题       # 必填，显示在页面顶部的标题
date: 2023-10-01 10:00:00  # 必填，文章创建日期（格式：YYYY-MM-DD HH:MM:SS）
updated: 2023-10-05 15:30:00 # 文章最后更新时间（可选）
categories: [技术, 编程]  # 文章分类（支持多级，如 [技术, 后端开发]）
tags: [Hexo, 教程, 静态博客] # 文章标签（无层级限制）
---

使用方法：在开头文章输入—，回车自动生成yaml块，注意yaml格式，：后必须有一个空格。

2.本地预览：启动开发服务器

1
2
3
hexo clean && hexo generate  # 清理旧文件并生成新静态资源
hexo server --debug          # 启动本地服务器（端口4000，带调试日志）

3.部署到 GitHub Pages

1
2
hexo clean && hexo generate  # 清理旧文件并生成新静态资源
hexo deploy                # 推送 public 目录到 GitHub

CI/CD 版本

2026/2/4

太棒了！恭喜你成功跑通了第一条 CI/CD 流水线！

从你的截图看，不仅 fix: convert submodule to normal folder 这个部署任务变绿了，紧接着 GitHub Pages 自己的 pages build and deployment 也变绿了。 这意味着你的网站现在已经是“最新版”的了。

现在，你的博客使用方式已经彻底改变，变得更符合现代开发流程。以下是你的“新操作手册”：

1. 现在的“发博客”流程 (SOP)

以前你需要 hexo clean -> hexo g -> hexo d，现在完全不需要这些命令了。

你的新流程如下：

  1. 写文章： 在本地 D:\blog\Hexo_blog\source\_posts\ 目录下，新建或编辑 Markdown 文件（依然可以用 hexo new "title" 帮你生成文件，或者直接复制粘贴）。

  2. 本地预览 (可选)： 如果你想看看效果，可以运行 hexo s 在本地浏览器 localhost:4000 看看。觉得没问题了就 Ctrl+C 关掉。

  3. 推送到云端 (发布)： 只需在 CMD 里执行这三行“黄金指令”：

    Bash

    1
    2
    3
    git add .
    git commit -m "upd: new post about fitness"  # 这里的提交信息随便写
    git push

  4. 坐等上线：

    • git push 成功后，你就可以关掉电脑去喝水了。
    • GitHub Actions 会在后台自动帮你 npm install，帮你 hexo g，然后帮你部署。
    • 大约 1-2 分钟后，访问 wenzieee.github.io，新文章就出来了。

2. 这个改变带来的三大好处

作为一个 CS 学生，你要明白你现在拥有了什么：

  • 多设备漫游：哪怕你换了一台只有浏览器的 iPad，你也可以登录 GitHub 网页版，直接在 source/_posts 文件夹里“新建文件”写 Markdown，点一下“Commit changes”，博客照样会自动更新！你不再被绑定在那台装了 Node.js 的电脑上了。
  • 版本回滚：万一哪天你把博客改崩了，或者误删了文章，Git 都有历史记录。你随时可以回退到上一个版本。
  • 纯净环境：再也不用担心“本地 Node.js 升级导致 Hexo 跑不起来”这种恶心事了，云端永远用的是干净、稳定的环境。

3. 给你的“最后一步”建议

虽然现在已经成功了，但我建议你做最后一次检查，确保万无一失：

  • 检查图片：去你的博客网站上看看，文章里的图片能不能正常加载？
  • 检查主题配置：点几个菜单，看看侧边栏、友链是不是都还在？

如果一切正常，那么恭喜你，你已经从一个“博客使用者”进化为了一个“DevOps 实践者”。以后面试时，你可以自信地把这个项目写在简历上，标注为：“基于 GitHub Actions 的 Hexo 博客持续集成与部署系统”。

回归版本

这是一个非常理性的决定。工具是为人服务的，如果 CI/CD 的等待时间（通常 1-2 分钟）让你觉得打断了写作的心流，或者你只是想改两个错别字，那么切回本地部署确实更高效。

切回“手动挡”非常简单，本质上就是把发布的权力从“云端机器人”手里收回到“你的电脑”上。

请按照以下步骤操作：

第一步：“解雇”云端机器人 (停用 GitHub Actions)

我们需要告诉 GitHub：“以后别自动构建了，我自己来。”

  1. 在你的本地电脑，打开 .github/workflows/deploy.yml 文件。
  2. 方案 A（删除）：直接把这个文件删了。
  3. 方案 B（重命名/备份 - 推荐）：把它重命名为 deploy.yml.bak。
    • 原理：GitHub 只识别 .yml 后缀的流程文件。改了后缀，它就失效了，但代码还在，万一哪天你想用回来，改回名字就行。

第二步：安装本地部署插件 (关键)

你的 CI/CD 脚本里用的是 peaceiris/actions-gh-pages 这个动作来发布的，它不需要 Hexo 的部署插件。 但现在你要在本地用 hexo d 命令，就必须安装 Hexo 官方的 Git 部署插件。

在 CMD 里执行：

第三步：配置部署地址

打开根目录的 _config.yml，滑到最底部，找到 deploy: 部分。 确保它长这样（把 repo 换成你的仓库地址）：

注意：如果你之前用的是 SSH (git@github.com…)，请确保你本地配置了 SSH Key。如果用的是 HTTPS，部署时可能需要输入 Token。

第三步：回归“旧”流程 (The Old Way)

现在，你又回到了熟悉的节奏。每次写完文章：

  1. 生成与部署：

    (这一套下来，本地通常只需要 10-20 秒)

  2. 备份源码 (千万别忘了！) 虽然你放弃了 CI/CD，但千万不要放弃版本控制。 发布完网站后，记得要把你的源码（Markdown 文件）推送到 GitHub 的 hexo-source 分支存档：

    如果这一步不做，万一你电脑坏了，你的所有文章源码就都丢了！

💡 进阶建议：混合双打模式 (Hybrid Mode)

其实，你不需要完全放弃 CI/CD。你可以保留它，作为“兜底”或“大版本更新”用。

怎么做？

  1. 保留 .github/workflows/deploy.yml 不动。
  2. 日常写文章/改错别字：
    • 在本地直接运行 hexo g -d。
    • GitHub Pages 会立即更新（因为是你强推上去的）。
    • 此时不要 push 源码到 hexo-source 分支。
  3. 定期备份/大改版：
    • 比如这周写了3篇文章，或者换了主题配置。
    • 此时执行 git push origin hexo-source。
    • GitHub Actions 会触发，它会重新构建一遍并覆盖你的部署。

好处：

  • 平时快：本地部署，立等可取。
  • 云端有备份：只要你定期 push 源码，云端永远有一套能跑的流水线。万一哪天你换了新电脑，没装 Node.js，你直接在 GitHub 网页上改 Markdown，也能自动发布。

你自己权衡一下，如果完全不想等 CI，就按步骤一二三彻底切回本地即可！

Gemini said

没问题，我把格式框去掉，直接发纯文本给你。

请复制下面这一行文字到 CMD 中执行：

npm install hexo-deployer-git –save

执行完上面那个命令后，请把 _config.yml 里的 deploy 部分改成下面这样（注意缩进）：

deploy: type: git repo: branch: main

这样能看到了吗？