修复记录 #7

序号： 7

问题概括： 将远程仓库地址从 HTTPS 改为 SSH 时，执行 git remote add origin 提示 error: remote origin already exists.

问题类别： Git 配置

影响范围： 本地 Git 仓库与 GitHub 远程仓库的关联

问题原因：

  • 技术根因： 本地仓库初始化后，已通过 HTTPS 协议添加了名为 origin 的远程仓库（https://github.com/stuffren/chunking-blog.git）。Git 不允许两个同名远程仓库同时存在，因此再次执行 git remote add 时因名称冲突而报错。
  • 大白话解释： 你想给快递柜登记个新地址，但系统说"这个柜子已经有地址了"。不能直接新增，只能修改已有的登记信息。

排查思路：

  1. 执行 git remote add origin git@github.com:stuffren/chunking-blog.git 报错 already exists；
  2. 执行 git remote -v 查看当前 remote，发现已存在 HTTPS 地址；
  3. 推断需要使用 git remote set-url 替换已有 remote 的 URL，而非重新 add；
  4. 执行 git remote set-url origin git@github.com:stuffren/chunking-blog.git 后验证通过。

最佳解决方法： 执行 git remote set-url origin git@github.com:stuffren/chunking-blog.git 替换已有 origin 的地址，而非 git remote add。

验证状态： ✅ 用户已确认（"SSH地址改好了"）

修复记录 #8

序号： 8

问题概括： 首次推送本地代码到 GitHub main 分支时被拒绝，提示 ! [rejected] main -> main (fetch first)。

问题类别： Git 同步

影响范围： 代码首次推送到远程仓库

问题原因：

  • 技术根因： 创建 GitHub 仓库时勾选了"Add a README file"，导致远程仓库存在一个初始提交（包含 README.md）。本地仓库是从零开始的全新提交历史，与远程历史不相关，Git 默认拒绝这种非快进且历史不相关的推送。
  • 大白话解释： 远程仓库比你早"出生"一天，还带着个 README 胎记。你直接往上冲，Git 保安说"等等，你身上没这个胎记，不能插队"。

排查思路：

  1. git push -u origin main 报错 rejected，提示 the remote contains work that you do not have locally；
  2. 回忆创建仓库时勾选了 Add a README file；
  3. 推断需要先将远程的初始提交合并到本地，使两边历史产生关联；
  4. 执行 git pull origin main --allow-unrelated-histories --no-rebase 合并不相关历史；
  5. 合并成功后再次执行 git push -u origin main，推送成功。

最佳解决方法： 先执行 git pull origin main --allow-unrelated-histories --no-rebase 合并远程初始提交，再执行 git push -u origin main。

验证状态： ✅ 用户已确认（"已经成功解决问题了"）

修复记录 #9

序号： 9

问题概括： GitHub Actions 构建成功但部署到 GitHub Pages 失败，报错 GH013: Repository rule violations found，提示 Push cannot contain secrets。

问题类别： 构建流程 / CI/CD 安全

影响范围： GitHub Actions 自动部署流程（Deploy to GitHub Pages 步骤）

问题原因：

  • 技术根因： deploy.yml 通过 env: VITE_GITHUB_TOKEN 将敏感 Token 注入构建环境。Vite 的默认行为是将所有以 VITE_ 开头的环境变量打包进前端 JS bundle（供浏览器端 import.meta.env 使用）。因此 Personal Access Token 被嵌入了 dist/assets/main-xxx.js 中。peaceiris/actions-gh-pages 将 dist 目录推送到 gh-pages 分支时，GitHub Secret Scanning 检测到 JS 文件中包含真实 Token，触发 Push Protection 机制，直接拒绝推送。
  • 大白话解释： 你把家门钥匙（Token）写在了快递单上（VITE_ 前缀变量），Vite 以为这是收货地址，直接印在了包裹外面（打包进 JS）。GitHub 安检一看："包裹上有钥匙，不能寄！"

排查思路：

  1. Deploy to GitHub Pages 步骤报错 GH013 Push Protection，提示 Push cannot contain secrets；
  2. 日志显示 assets/main-ClyvosFV.js:9 中包含 GitHub Personal Access Token；
  3. 分析 Vite 构建机制：所有 VITE_ 前缀变量会被自动注入前端代码；
  4. 检查 deploy.yml 确认 VITE_GITHUB_TOKEN 被传入了 build 环境；
  5. 推断 Token 被打包进了 JS bundle，导致部署产物中包含敏感信息；
  6. 提出方案：将敏感 Token 的变量名改为非 VITE_ 前缀（GITHUB_TOKEN），使 Vite 忽略它；同时修改 build-ssg.js 支持从 process.env.GITHUB_TOKEN 读取；保留其他需要暴露给前端的 VITE_ 变量（如 VITE_GISCUS_REPO_ID）不变；
  7. 修改后重新触发 workflow，部署成功。

最佳解决方法：

  1. 修改 build-ssg.js：将 Octokit 认证改为 new Octokit({ auth: process.env.GITHUB_TOKEN || process.env.VITE_GITHUB_TOKEN })；
  2. 修改 deploy.yml 的 .env 创建步骤：不再写入 VITE_GITHUB_TOKEN；
  3. 修改 deploy.yml 的 build env:：将 VITE_GITHUB_TOKEN 改为 GITHUB_TOKEN；
  4. 其他非敏感变量（VITE_GISCUS_REPO_ID、VITE_GISCUS_CATEGORY_ID 等）保持 VITE_ 前缀不变。

验证状态： ✅ 用户已确认（"目前github action的workflows列表中已经看到部署成功了"）