又一次重建 Hexo Blog
本文最后更新于:2025年10月21日 早上
昨天想更新 blog,没想到就是下午迁移出了问题,然后又是花了一个晚上排查问题。后来才发现好简单……所说是无用的调试,还是记录一下,免得以后又遇到。
掉进坑(无用调试)
执行 git pull origin main 后出错
1 |
|
提示远程仓库不存在,问了 ChatGPT 说是SSH 密钥的问题,生成公钥和私钥重新添加后也不起作用。
ls -al
后有 .git 文件,确认下命令行有没有走代理流量
1 |
|
返回正常,再看看能不能连接到 GitHub
1 |
|
输入 yes
也是正常。看看 git branch 在哪个分支上,是 main。
在 GitHub-Code-Local-SSH 直接复制项目名,执行
1 |
|
输入后没反应是正确的,接着
1 |
|
再确认分支有没有错
1 |
|
接着查看当前 Git 仓库的本地配置文件内容的命令
1 |
|
接着查看当前 HEAD(最新提交)的一些详细信息
1 |
|
这些看着都没问题那就只好重新 clone 一下了。重新 push 创建了新的 main 分支
1 |
|
我把 Default 设置为 main,把 master 删除。重新 clone 一下 main 分支。更改默认分支后进行 clone。
移动再克隆
第一步直接 mv
1 |
|
bak 就是 backup 的缩写
第二步 git clone
1 |
|
重新安装 Hexo
1 |
|
奇了怪了,Homebrew 也不生效,其实并不是没了,而是当前 PATH 没指向 /opt/homebrew/bin。干脆就全部安装下吧。要开启 Qutumult X 开启 SS 服务器功能,不然没有代理无法下载。安装 Homebrew
1 |
|
要执行下面三条命令才能安装
1 |
|
clone 之后文件夹重命名,重新安装 Hexo
1 |
|
水落石出
就在我以为重装能成功之后结果还是不行,越弄越烂,最后还是麻烦余光帮我排查,在私人仓库添加一个 collaborator,他上去一看就发现问题所在。
仓库和 Cloudflare 所关联的根本不是同一个!半年前我已经迁移到 Cloudfare,新建了一个 repo,全然忘记老的仓库不再使用,所以牛头不对马嘴😅
Clone 正确仓库
那接下来就简单了,重新备份(昨晚已经备份过,跳过),然后再 clone。类似于重启大法,对正确的这个仓库没有进行过操作,都不用安装 Homebrew,Hexo,所以异常的快速简单。
使用 GitHub 图形界面
这一次,终于抛弃那些繁琐的命令,本来就搞不懂。下载 GitHub 图形界面,登陆 GitHub 账号,然后设置 git config 关联的邮箱,因为 git 标准里要求必须有邮箱(和登录的 GitHub 账号没有关系),可以选择匿名邮箱账号,为了不出幺蛾子用自己邮箱登陆,选中仓库(别再选错),一键 Clone,选择保存路径。
然后只有两步,Commit to main 然后 Push origin,搞定。想看本地渲染的还是
1 |
|
如果提示没有项目依赖就装一个,都不用全局安装
1 |
|
大功告成!感谢余光,FriendsA 帮我排查了这么久时间🙏
疑难点
之前排查的过程中,老 repo 的线上分支 Default 是 master,但是也有 main,以为是项目的 master 和 main 不同导致的错误。(这两个其实只是名字区别,只是最近主流都用 main 了)
branch 指的是 Hexo push 的远程分支。如果 Git 仓库默认分支是 main,_config.yml 必须写 main,否则 Hexo 会往 master 推送(即使你的本地 default 是 main)只修改 _config.yml 并没有提交,这个修改是本地未保存的 Git 改动。Hexo 会用最新的文件夹去 push,但 Git 依旧会检测到本地未提交改动。因此,如果想 Hexo push 到 main,最好先把 _config.yml 的修改提交或保存,避免被 Git 阻止。
在 _config.yml 中修改
deploy:
type: ‘git’
repo: [email protected]:luckylele666/luckylele666.github.io.git
branch: master
master 修改为 main
如果是在本地部署可以这样设置,但是我现在的构建方式不是这样了。
原理
传统 Hexo 部署
以前常用的流程:Hexo 本地 → hexo g(生成静态文件) → hexo d(推送到远程服务器/仓库)
- _config.yml 的 deploy配置是关键,指定仓库和分支
- Hexo 自己负责生成 public/ 并把它推送到 GitHub 或其他远程
- 必须在本地先生成,再上传
不足:
- 每次修改都要本地生成
- 本地要安装完整 Hexo 环境(Node、主题、插件)才能生成
Cloudflare Pages 部署
我现在的模式是:GitHub 仓库(纯代码,私人仓库,更加隐私) → Cloudflare Pages(自动构建 & 发布)
特点:
- 自动化构建:Cloudflare 会在 push 到 main 分支时自动执行 Hexo generate,生成 public/ 并直接发布到站点
- 不依赖 Hexo deploy,不用再在本地运行 hexo d,也不需要在 _config.yml 里配置分支
- 纯 Git 流程:只需要用 git add → commit → push 管理版本,Cloudflare 会负责构建和部署(用了 GitHub 图形管理界面甚至都不用 Git 命令)
为什么不用 hexo g,hexo d
因为 hexo d 其实做了两件事:
- 生成静态文件(hexo g)
- 把生成的 public/ 推送到指定远程分支(hexo d)
而 Cloudflare 已经代替了第 2 步:
- Cloudflare 会在云端执行构建(等同于 hexo g)
- 自动把生成结果发布到你的 Pages 网站
所以本地运行 hexo g hexo d 反而是多余的,甚至可能把 Git 历史搞乱(尤其是 _deploy_git/ 里嵌套 Git 仓库的情况)。
用下来个人感觉在代码方面,免费版之间,ChatGPT>Grok>Gemini,不要太过于相信 AI 的答案,现阶段感觉还是不如人脑。
💡注释
- ~ 是 用户>xxx 的别名
- cd 是 change directory(切换目录) 的缩写
- ~ 表示 当前用户的主目录(home 目录)
- /blog 是主目录下的一个子文件夹