从本地修改到线上更新，中间发生了什么？

保存文件只是第一步

本机编辑后先预览正文、链接和布局。保存不会自动产生 Git 历史，也不会自动改变网站。明确这一点，就能避免“明明修改了，为什么别人还看到旧版”的困惑。预览地址和正式域名应分别标识，避免分享错入口。

一次提交表达一件事

提交应解释为什么改、改了什么。只包含相关文件，不混入密钥、生成物或其他项目改动。推送把记录交给远程仓库；采用合并请求时，审核并合并后才进入约定的发布分支。先检查差异，再提交，比事后找回误传文件容易。

发布选择一个具体版本

部署将指定版本的构建结果交给托管环境。博客和导航可能共用仓库但输出不同目录，必须确认目标，不能误传私人内容。凭据使用专用秘密存储，日志只保留必要信息。

用读者视角完成验收

已登录浏览器不能验证所有访客体验。公开页面用未登录方式测试，私人页面确认仍要求验证。若有问题，先区分内容版本、域名路由和访问权限，不把所有异常都理解成“需要再发布一次”。

先确定这次要公开的唯一变化

本篇任务是把个人博客的一次正文修订送到正式地址，并证明读者看到对应版本。准备已有个人仓库、当前分支、发布分支约定、项目检查脚本和正式域名。本文不假定推送就自动部署，也不默认所有仓库都用同一种工作流。先阅读实际项目的发布配置，写明由什么事件触发、构建哪个目录、交给哪个站点。示例路径和记录均为占位，未执行提交、推送或部署。

把本次变化写成一句话，例如“补全文章的验收步骤”。随后保存编辑器文件，检查正文、链接和附件，不把顺手修改的其他文章混进来。公开稿与私人草稿可能共用工作目录，因此本地预览可见不代表允许发布。先明确源文件范围及生成物范围，才能在暂存与构建时作出选择。保存只改变磁盘文件，Git 提交和网站部署仍是后续独立动作。

git status --short --branch
git diff -- article.md
git add -- article.md
git diff --cached -- article.md
git diff --cached --check
# 确认内容和项目检查完成后，才执行下一条
git commit -m "补全文稿验收步骤"
git show --stat HEAD
git status --short

提交前审查的是下一份快照

先看状态与普通差异，再按明确路径暂存并查看 cached 差异。普通差异面向未暂存编辑，cached 差异才是下一次提交的主要候选内容；暂存之后继续改文件会让两者不同。检查标题、日期、正文、附件引用与意外配置，确认不含真实账号或私人入口。新附件可能没有出现在普通 diff 正文里，应在编辑器单独检查。

项目检查通常读取工作区，若工作区还有未暂存的依赖改动，成功结果不一定证明暂存内容独立成立。简单文字修订也要确认没有依赖未暂存附件或索引更新；复杂代码变化可用独立副本验证具体提交。提交说明写为什么改和影响哪里，提交完成再看最新记录和剩余状态。钩子可能改变文件，因此一次 commit 成功也不是忽略后续差异的理由。

推送、合并与部署分别找证据

推送把本地提交交给远端分支，是否公开取决于仓库工作流。若采用合并请求，先检查远端分支内容与本次提交一致，再完成约定审核与合并；发布分支收到的最终提交可能与原分支不同，应记录实际发布来源。不要把本地提交标识直接写进线上验收而不核对工作流选中的版本。

部署任务需要查看实际运行结论、源版本、环境和产物目标。排队、启动、构建完成、上传完成与最终成功不是同一个阶段。GitHub 文档还说明重新运行既有工作流仍关联原来的提交与引用，不能指望重跑旧任务自动取到新修订。涉及凭据使用平台专用秘密存储，日志仅保留必要信息。本文的记录模板不存凭据，读者应在自己的既有发布流程中填写运行标识与结果。

# 文章发布记录
变化：补全文章验收步骤（示意）
源文件：<待填>
本地提交：<待填>
远端目标分支及对应提交：<待填>
合并后发布来源：<待填或不适用>
工作流/部署运行：<实际标识>
环境与产物目录：<待填>
最终部署状态：<未执行/成功/失败>
正式URL：https://example.com/articles/example
正文辨识点：<本轮新增公开文字>
验收：正文/目录锚点/图片/RSS/深链接刷新/<各填结果>
私人入口：<仍需身份/待测>
说明：推送、合并与发布按仓库既有流程执行，不由本模板触发。

完整案例：提交成功，正式站仍是旧段落

构造情景中，本地已经提交文章新增验收段，正式地址仍看不到。先检查远端目标分支是否包含该提交；若还未推送，问题尚未进入部署阶段。若提交在功能分支而发布只监听主分支，就核对是否完成合并。若发布任务存在，则查看它选中的提交和最终状态，而非连续点击重跑。这样每一步都能找到一个明确的交接证据。

假设部署成功但选中了旧提交，先按既定流程触发正确版本，再做读者验收。若版本正确但内容旧，核对正式域名绑定、实际产物目录与缓存；用本轮新增的独特公开文字作为辨识点，并检查脚本和图片是否来自同一版本。不能仅看首页外观相同就说失败，也不能仅看绿色任务就说成功。本文没有真实发布记录，模板中所有结果待填，不会把假设链路写成亲历故障。

正式验收包含内容和边界

用未登录会话打开正式域名，再直接打开修订文章，检查新增段落、目录锚点、图片与参考链接。刷新深链接以验证服务器路由；在窄屏上阅读长代码块，确认内容没有无法访问的裁切。首页、归档和 RSS 若应反映本次更新，也各抽查一个入口。验收对象必须是正式地址，不能误用仍打开的本机预览标签页。

私人写作台、导航和接口继续检查身份要求，不能因为发布正文而降低保护。macOS 与 GNU/Linux 的 Git 基础语义一致，但构建依赖、文件大小写及 shell 语法有差异；DSM 若只是目标服务或存储位置，不应顺手在其系统目录运行仓库命令。下面 Git 命令只适用于普通已有提交的个人仓库，具体脚本仍以项目定义为准，模板避免把未确定的分支名当成可直接推送的指令。

# 发布恢复记录
当前线上版本：<待填>
故障症状：<具体路径与观察>
目标已验证版本：<待填>
恢复方式：<平台恢复产物/修正提交后发布>
源仓库配套修正：<待填>
覆盖或中断影响：danger，确认当前与目标
恢复后文章/附件/深链接：<待测>
恢复后私人边界：<待测>
仍未解决：<待填>
下次发布防止复发的检查：<与故障直接相关的一项>

恢复是一条新的可追踪发布

发现线上问题时，先区分撤回内容还是恢复部署版本。托管平台若支持恢复已验证产物，可依既有流程选择该版本并重新验收；源仓库也要留下对应修正，避免下一次部署把错误再次带回。对已共享提交通常用反向提交保留历史，但要先核对目标和后续依赖，不能随便反向处理最新提交。

恢复产物或覆盖线上版本属于 danger，因为它会改变读者当前看到的内容。执行前记录当前与目标版本，执行后重测原路径及私人边界。收尾把源提交、部署运行、正式 URL、验收和恢复目标关联在一份发布记录中。未执行的项目写未执行，失败的项目保留错误摘要；这份证据链才真正回答“从本地修改到线上更新，中间发生了什么”，而不是只留下一个完成按钮截图。

填写工作表，把示例变成自己的记录

文中的命令停在本地提交，远端推送和正式发布使用记录表对接项目既有流程。这是为了避免在不清楚发布分支的教程里提供一个看似通用却可能选错目标的指令。命令中的 article.md 是示例路径，应先替换为已确认的个人文章文件；若文件不存在，就停止并检查目录，而不是改成整个仓库的批量暂存。每条命令完成后阅读结果，提交前再次确认暂存差异。

发布记录不预填提交标识和工作流编号，因为这些只能从真实运行取得。把“提交已存在于远端”“部署选中这个版本”“正式页面有新增段落”作为三个独立核对项，可以准确定位中间断点。恢复记录则保留当前版本和计划恢复版本的对应关系，以及实际验收结果。若部署流程由另一位所有者维护，交付审查过的变更与记录即可，不能未经授权替其修改托管目标。填写后的模板应足以让未来的自己重建这次发布经过。