修改hexo编辑器和后端

正常【推送】（安全推送 /api/safe‑push）VS 应急【⚠️强制推送】（旧接口 /git‑push）

注意：应急强推并不是 git push --force，还是普通 git push，只是跳过 “预先检测远端新提交 + 弹窗确认 + 自动变基拉取” 整套安全逻辑Git。

✅正常推送（页面上【推送】按钮，新写的安全逻辑）

完整执行流程：

1. 先执行 git fetch origin，拉取远端最新提交哈希，对比本地 main 和 origin/main 的 commit 哈希

2. 如果发现：远端 GitHub 有别人 / 别的设备新提交 → 弹出浏览器确认框

   • 提示：远端存在新提交，需要执行 git pull --rebase origin main（变基）把远端代码合并到本地，之后再推送
   • 你点确定：后台执行变基拉取 → 有改动自动 commit → 再 git push；变基遇到冲突会直接返回冲突提示，停止操作，不会乱覆盖
   • 你点取消：整个推送直接终止，什么都不做
3. 如果本地与远端哈希完全一样（没有远端新提交）：直接 add、commit（有改动才提交），然后 push

优点：

• 保护你，不会因为 NAS 本地版本旧，直接推送被 GitHub 拒绝
• 远端有新代码会提醒，自动做变基合并，冲突会给提示，不会丢远端内容
  适用：99% 日常写博客，全部点这个。

变基冲突的时候你要登录容器手动处理 git 冲突，编辑器页面只会告诉你 “发生冲突”，不会自动修复。

⚠️应急强制推送（下拉框选项：⚠️强制推送 (应急)，老接口 /git‑push）

它不是 git push --force，仍然是普通 git push！只是完全跳过前面的远端哈希检测、弹窗确认、自动 pull‑rebase 整套保护逻辑。

执行流程：

1. 不做任何远端哈希比对，不询问你
2. 直接执行：git add .，有变更就自动 commit，然后直接执行 git push origin main

会遇到的情况

1. ✔️本地版本 >= 远端版本：push 成功，和正常推送效果一样；
2. ❗本地版本落后 GitHub 远端（GitHub 有新提交）：GitHub 直接拒绝 push（非快进拒绝 non‑fast‑forward），操作直接失败Git。

它不会自动帮你拉取合并远端代码，直接报错终止。

什么时候才用这个应急选项？

1. 你已经自己手动在 SSH 里执行过 git pull / git pull --rebase，已经处理完远端同步；编辑器的安全检测逻辑卡住异常，不想走检测弹窗；
2. 排查 git 故障，手动处理完仓库，只需要单纯提交 + 推送；

⚠️不要日常写博客用这个！ 当你在别的电脑修改过 hexo 仓库，NAS 本地旧，点应急推送直接报错，不会自动帮你合并远端更新。

补充：真正毁灭性的 git push --force（本编辑器没有这个按钮！）

git push --force 会强行用本地直接覆盖 GitHub 远端仓库，远端 GitHub 独有的提交会直接被抹除丢失，这个编辑器没有实现这个高危功能，应急选项≠强制覆盖，这点不要混淆Git。

极简对比表格

表格

实操建议

1. 平时写文章，一律点【推送】按钮，不要碰下拉的应急强推；
2. 如果正常推送弹出提示框说远端有新提交，点确定让程序自动变基；报冲突，进容器手动处理 git 冲突；
3. 只有 SSH 手动操作过 git 仓库，确认本地已经同步完远端，才使用那个下拉的应急选项。

代送、代拉按钮不受这两个逻辑影响，是老的代理 git 命令，用于网络不通 github 的走代理。