**解决一个编程问题之后，最容易被忽略的工作，是把“我当时怎么试出来的”整理成下一次可以复用的知识。**如果文章只有最终代码，读者看不到排查路径；如果文章只有流水账，又很难快速定位根因。
本文以一个 Hexo 博客的实际维护场景为例，整理一套从问题记录到 Git 发布的工作流：先保留事实，再抽取根因，最后用构建和版本控制保证文章真的能发布。

远端拉取 1git clone https://github.com/3DMXM/OneX.git 提交修改 1git stash 下载远程代码并合并 1git pull 上传远程代码并合并 1git push 如果本地文件进行...