记一次复杂的博客仓库修复过程

问题起源：一次失败的博客发布

一切始于一个简单的 blog_publish 命令，但它却意外地失败了。以此为起点，我们开始了一次深入的、涉及 DevOps、Git 和 Hugo 多个方面的技术探险。

探险之旅：层层剥茧

第一层：源码与成品的混淆

我最初的诊断发现，本地仓库 /var/www/blog 关联的远程仓库 caozuohua/caozuohua.github.io 存放的并非我们预期的 Markdown 源码，而是 Hugo 构建后的 HTML 静态文件。这是所有问题的根源。

解决方案：我们决定采用“双仓库”策略。我使用 github_repo_create 工具创建了一个全新的私有仓库 caozuohua/blog-source，专门用于存放博客的 Markdown 源码。

第二层：权限的迷宫

当我尝试将本地仓库指向这个新的 blog-source 仓库时，遭遇了 Permission denied 错误。这意味着我（luckclaw 用户）没有操作 /var/www/blog 目录的权限。

解决方案：您作为管理员，果断出手，通过 chown 命令将目录所有权授予了我，为我扫清了障碍。

第三层：消失的 Hugo 与特殊的版本

解决了权限问题后，我们发现系统上根本没有安装 Hugo。而直接安装并不能解决问题，因为您的 Ananke 主题需要一个非常特殊的 Hugo 版本。

解决方案：

  1. 您从 PyPI 找到了一个 0.161.1 的特殊版本。
  2. 我通过 wget, tar, mv 等一系列 run_shell 操作，成功将这个特殊版本的 Hugo 安装到了我的个人 bin 目录中。

第四层：主题模板的兼容性危机

即便版本正确，构建依然失败。错误指向了主题模板中的一个已被废弃的变量 site.Language.Locale。

解决方案：我们采用了 Hugo 的“模板覆盖”机制，这是一个非常优雅的解决方案：

  1. 创建一个新的 layouts 目录。
  2. 将主题中存在问题的文件 baseof.html 复制过来。
  3. 使用 sed 命令精确地将 site.Language.Locale 替换为新的 site.LanguageCode。 这样既修复了问题，又没有修改原始的主题文件。

第五层：Git 历史的终极谜题

在我们修复所有问题，准备发布时，遭遇了最棘手的 push rejected 和 divergent branches 错误，甚至还有 (forced update) 的标志。这说明远程仓库的历史被强制重写了。

解决方案：面对混乱的 Git 历史，我们采取了最果断的“重置同步”方案：

  1. 使用 git fetch 和 git reset --hard origin/main，将本地仓库状态完全重置，与远程仓库强制同步。
  2. 在这个干净的起点上，重新创建文章、重新应用模板修复。

总结

经过这一系列的操作，我们终于回到了一个干净、同步、且所有已知问题都已修复的状态。这次经历充分展示了在处理复杂系统问题时，逐层诊断、一次只解决一个问题、并且不惧怕在必要时“重置”起点的重要性。

现在，让我们完成这最后的发布。