文章

博客更新规范推文

博客本地修改GitHub 推送标准流程（避坑指南）

发表于
作者 墨殇
3 分钟阅读
博客更新规范推文

博客本地修改 & GitHub 推送标准流程（避坑指南）

一、核心正确流程（最重要、以后固定照做）

完整顺序

本地修改文件（写文章 / 改配置）→ 本地提交 → 拉取远程同步 → 推送远程

分步标准命令（Termux 专用）

1
2
3
4
5
6
7
8
9
10
11

# 1. 暂存所有本地修改
git add .

# 2. 提交本地修改（自定义备注）
git commit -m "更新：新增推文/修改配置/修复内容"

# 3. 拉取远程最新代码，合并到本地（关键！防止推送报错）
git pull

# 4. 正常推送到 GitHub 远程仓库
git push

一键懒人命令（推荐日常直接用）

1

git add . && git commit -m "博客日常更新" && git pull && git push

二、为什么必须「先 pull、后 push」

  1. GitHub 远程仓库会自动生成部署日志、CI 缓存文件，导致远程版本永远比本地新一点点。

  2. 如果修改完直接 git push，一定会报错：non-fast-forward 推送被拒绝。

  3. 先 pull 是同步云端差异，不会覆盖你本地修改的文件，只会合并远程新增内容。

三、绝对禁止的操作（踩坑总结）

  1. 不要频繁使用 **git push -f** 强制推送

    • 仅本地版本彻底错乱时临时救急使用。

    • 长期乱用会导致云端提交记录断层、历史文件丢失。

  2. 不要本地修改后直接 push

    • 必报版本落后错误，反复卡死。

  3. 不要残留临时文件

    • 操作产生的 tmp、缓存文件一定要删除，避免提交垃圾文件到仓库。

四、遇到报错专属解决方案

报错 1：本地有未提交修改，无法 pull

1
2
3

git add .
git commit -m "保存本地修改"
git pull

报错 2：弹出 vim 合并界面

  1. 按 Esc

  2. 输入 :wq 回车保存退出

  3. 继续 git push

报错 3：存在垃圾临时文件

1
2

rm -f _posts/tmp
git add . && git commit -m "清理临时文件" && git push

五、单人博客最优维护原则

  1. 永远遵循：改完 → 提交 → 拉取 → 推送

  2. 单人仓库无需复杂分支，全程 main 主分支即可

  3. 只在紧急修复版本错乱时，使用一次强制推送

  4. 每次推送前保证仓库干净，无多余临时文件

教程, 示例
Chirpy 推送 避坑
本文由作者按照 CC BY 4.0 进行授权