Git 快照、检查点与回滚
系列入口：如何使用 Agent。本篇是 M7 工作流 SOP 的第一篇，为 Agent 调试、重构、测试先行等所有会改动代码的流程打底。
一、为什么这是一切自动化的前提
Agent 改代码的速度远超手写，几分钟就能铺开几十个文件。这是效率来源，也是风险来源：一旦方向走偏，它同样能在几分钟里把一大片代码改乱。如果动手前没有一个明确、干净、可回退的基线，你面对一堆改动会非常被动——哪些是它改的、哪些是你原来的未完成工作、能不能安全撤回，全都纠缠不清。
Git 快照的本质，是在「让 Agent 自由发挥」和「随时能退回安全状态」之间架一张安全网。 有了它，你才敢放手让它尝试更大胆的方案：成了就保留，错了就退回到上一个确认可用的点，损失被严格限定。这种「可回滚」不是胆小，而是让你敢于试错的底气。
二、任务前：先确认基线干净
让 Agent 动手前，第一件事不是描述需求，而是看清当前工作区状态。
2.1 先看有没有未提交改动
如果工作区里本来就堆着你没提交的改动，Agent 的修改会和它们混在一起，出问题时分不清责任，也难以整批回退。稳妥做法是先把已有改动处理好：能提交的提交成一个有意义的节点，暂时不想提交的用 stash 暂存。目标是让 Agent 从一个干净、你能清楚描述的起点开始。
这里有个常见误区：觉得「反正都是我自己的改动，混一起没事」。真正出事时你才发现，想退回 Agent 的改动却怕连带删掉自己原来的工作。多花一分钟清理基线，能省下大量事后纠缠。
2.2 为任务单独建分支
更稳的做法是为这个任务开一条专用分支，让 Agent 的所有改动都落在分支上，与主干隔离。这样即使改得一塌糊涂，也只是这条分支的问题，主干始终保持可用；你可以随时放弃整条分支，也可以在验证通过后再合并。分支是比「在主干上直接改」粗粒度、却更省心的一层保险。
2.3 拍一个明确的基线提交
在分支上、开始改动前，先确认存在一个代表「当前可用状态」的提交，并记住它。这个基线就是你最坏情况下的退路。如果工作区干净且已有合适提交，不必特意再拍；关键是你心里清楚「退回哪里算安全」。
三、任务中：按阶段打检查点
一个任务常分几个阶段：先调研、再实现、后补测试。不要等全部做完才一次性提交，而应在每个确认可用的阶段结束时打一个检查点。
检查点的价值在出错时才完全体现：如果第三阶段的改动出了问题，你不必放弃前两阶段的成果，只需退回到第二个检查点。检查点越密、越对应「已验证的小成果」，你能精细控制的回退粒度就越小，返工成本越低。反过来，如果几千行改动只存成一个巨大的提交，任何一处出问题都可能连累整体。
打检查点时注意两点：一是尽量在「测试通过、状态确实可用」时提交，别把明知坏掉的状态标成检查点，否则这个点根本不可靠；二是提交信息写清这一阶段完成了什么，回头你才能一眼判断该退到哪。检查点不是为了形式，而是为了制造一串「随时可以落脚」的安全台阶。
四、出错时：三种状态，三种退法
回滚最容易出错的地方，是没分清你要撤回的是哪个层面的东西。Git 里有工作区、暂存区、提交三层，退法和后果都不同，用错可能丢掉本来想留的东西。
4.1 撤回工作区里未提交的改动
如果 Agent 刚改了文件、你还没提交，看过发现方向完全错了，想把某些文件恢复到上次提交的样子，可以按文件检出。这会丢弃这些文件上未提交的改动，不可恢复，所以执行前先确认这些改动确实不要了，必要时先备份或先提交一个临时点。
4.2 退回已经提交的历史
如果错误已经被提交，有两类思路，差别在于「要不要改写历史」。
- 还原（revert）：生成一个新的提交，内容是把某次旧提交的改动反向抵消。历史被完整保留，适合已经推送给别人、或你不想动历史的场景，安全且可追溯。
- 重置（reset）：把分支指针直接移回 earlier 的提交。可选是否保留那些改动在工作区。它更直接，但会改写历史，因此只适合还没推送、或纯粹本地的提交；对已经共享的提交随意重置，会给协作者制造混乱。
一个简单判断：改动已经推到远程、可能被别人基于它工作，优先 revert；只在本地、确定没人依赖，可以用 reset。 拿不准时，选更安全的 revert，或先新建一条分支做实验，避免在原分支上做不可逆操作。
4.3 只回退一部分
有时不是全盘皆错，只是某几个文件想退回、其余保留。这时可以只针对指定文件检出旧版本，或用交互式方式拣选，而不必整条回退。精细操作的前提仍是你清楚每个检查点包含什么——这又回到了清晰的提交信息和分阶段提交。
五、把这套动作交给 Agent 时的注意事项
你可以让 Agent 帮你执行建分支、提交、回滚，但有几条边界要守住。
第一，涉及丢弃改动或改写历史的命令，让人确认。这类操作一旦误判，可能丢掉你或他人的工作，不能让 Agent 在你没看清时自作主张。第二，要求它在每个阶段提交前先跑测试、确认状态可用，而不是机械地频繁提交不可靠的点。第三，让它在回滚前先说明「要退到哪里、会丢弃什么」，把后果讲清楚再动手。
核心原则和数据库写操作一致：让 Agent 承担繁琐的命令执行，把不可逆的决定权留给人。 当建分支、提交、还原这些动作被固定成每次任务的默认流程，你和 Agent 都能在一个始终可回退的环境里工作，试错的心理负担会显著降低。
五点五、一个真实的「省了一分钟，赔了一下午」
讲一个把快照纪律全部打破、代价惨重的真实场景。
小李接到一个紧急改动，急着让 Agent 上手，既没看工作区、也没建分支，直接在主干上开干。而他的工作区里其实还压着上午没写完的另一项实验。Agent 高效地改了二十多个文件，跑了两下看似没问题，他就继续往下做。一小时后，他发现 Agent 改坏了一个核心流程，想回退——可这时改动早已和他上午的实验、以及 Agent 的多轮修改混成一团。他既不敢整体 reset（会丢掉自己的实验），也无法辨认哪些文件是哪次改动产生的，只能手动一个个比对，整整耗掉一个下午，还差点把主干搞坏。
复盘看，事故链条的起点极其简单：跳过了「确认基线干净」这一分钟。 若他当时先 stash 自己的实验、建一条任务分支、再让 Agent 动手，那么最坏情况也只是放弃这条分支，几秒钟回到干净主干。这个对比值得记住：快照不是额外负担，而是把「可能赔一下午」提前用一分钟对冲掉。
还有个隐蔽点：他当时觉得「跑了两下看似没问题」，就默认状态安全，没打检查点。于是连一个中途能落脚的地方都没有。基线干净 + 分支隔离 + 阶段检查点这三件事是层层兜底的，任何一个环节省掉，出事时的回旋余地都会骤减。
五点六、提交粒度的艺术：太粗和太细都不好
打检查点听起来简单，但「多久提交一次」其实有讲究，太粗和太细都会出问题。
太粗，就是前面说的：几千行、跨好几个阶段的改动塞进一个提交。出问题只能整批退回，大量本来正确的工作被连累；评审者也根本看不懂这坨改动在做什么。太细则是另一极端：每改一行就提交，历史里堆满「改一下」「再试试」的噪声提交，你反而找不到哪些点是真正「验证过、可以落脚」的，回退时无所适从。
健康的粒度对应一个**「可独立验证的小成果」**：完成一件完整的小事、且测试通过，就提交一次。比如「完成输入校验并补测试」是一个好节点；「改了第三行的空格」不是。判断标准可以问自己：这个提交之后，如果接下来全改崩了，我愿不愿意退回到这里、并且它确实能正常工作？答案是肯定的，它才配当一个检查点。
好的提交信息同样重要。它应说清「完成了什么、为什么」，让你三天后回看也能一眼判断该退到哪。把粒度和信息一起做好，你的提交历史就不再是流水账，而是一串语义清晰、随时可落脚的安全台阶。
五点七、和远程协作时，回滚多一层顾虑
前面多在本地视角，但一旦涉及远程仓库和团队，回滚的选择要更谨慎，核心是「别给协作者制造麻烦」。
关键区别在于：本地提交可以随意改写，已经推送、可能被他人拉取或基于它工作的提交，不应再被 reset 抹掉。 设想你把一个提交 reset 掉、又强推到远程，而同事已经基于那个提交写了新代码，他下一次拉取就会遭遇历史冲突，团队协作瞬间混乱。因此对已共享的历史，正确工具是 revert——它不删除旧提交，而是新增一个「反向抵消」的提交，历史对所有人保持连续、可追溯。
还有一个习惯值得养成：涉及强推（force push）的操作要极其克制，尤其在共享分支上；宁可多一个 revert 提交，也不要为了「让历史好看」而冒险改写。把「这条改动有没有别人会看到」作为选择回退方式的第一道判断，你就能在保护自己工作的同时，不破坏团队的协作基础。
五点八、reflog：你以为丢了，其实还在
讲一个常救人于绝境的底层机制。很多人在误 reset、误删提交后以为工作彻底没了，其实短期内大多能找回——关键是知道 reflog 的存在。
Git 会在本地记录 HEAD 和分支指针的每次移动，哪怕那些提交已经不在任何分支上。于是当你 reset 退错了点，可以查看 reflog 找到操作前的那个提交哈希，再把分支重置回去，工作就恢复了。这给「改写历史」类操作提供了一层事后缓冲，让它们没那么可怕。
但要清醒两点：reflog 主要是本地、短期的记录，会随时间过期清理，不能当作长期备份，更不会同步到远程；它救的是「我刚手滑了」，救不了「上周就丢了、还换了机器」。因此正确顺序是：执行不可逆操作前先确认目标、尽量在新分支试；真出意外，第一时间用 reflog 找回，而不是拖延或继续操作把痕迹冲掉。知道有这道兜底，你在让 Agent 操作时能多一分从容，但别因此放松了前面的纪律。
五点九、把整套 SOP 做成一句顺口的口诀
最后帮你把这套动作压缩成好记的口诀，便于每次开工自然想起。
可以记三步：「先看清、再开线、分段存。」「先看清」是动手前查看工作区、把原有改动提交或 stash，确认基线干净；「再开线」是为任务建专用分支、与主干隔离，并明确可回退的基线点；「分段存」是任务中每完成一个测试通过的小成果就打检查点、写清信息。出错时再加一句：「本地能 reset，推送就 revert。」
口诀的意义不是替代理解，而是降低执行门槛——当这套动作变成不假思索的肌肉记忆，你就不会因为「这次太急」「应该不会出事」而跳过。把它贴在显眼处、或干脆做成一个开工前调用的斜杠命令，让安全网在每个任务起点都自动就位。
六、常见问题
Q：我经常忘记打检查点，怎么办？ 把它和「完成一个可验证小阶段」绑定：测试一通过就提交，而不是等做完。也可以在任务说明里明确要求 Agent 分阶段提交并先跑测试，让流程由 Agent 提醒和执行。
Q：stash 会不会把改动弄丢？ stash 只是把改动收起来、可随时恢复，适合临时清理工作区；但要记得 stash 列表里还存着东西，事后及时 pop，避免遗忘。
Q：reset 后发现退错了，还能救吗？ 很多情况下可以通过 reflog 找到之前的提交再恢复，但这属于事后补救、不该依赖。执行 reset 前先确认目标提交，拿不准就在新分支上试。
Q：Agent 自动提交会不会提交一堆垃圾？ 所以要约束提交粒度和前提：只在阶段完成且测试通过时提交，信息写清；并在最终合并前整体审查一遍历史。
Q：每次都建分支会不会太繁琐？ 对一两行的小改确实可以更轻；但只要任务会铺开多文件、或存在走偏可能，分支隔离的几秒钟就远胜于事后纠缠。把建分支和打检查点做成固定脚本或命令，成本几乎为零。
七、任务前检查清单
- 已查看工作区状态，原有改动已提交或 stash，基线干净。
- 为任务单独建了分支，与主干隔离。
- 明确了可回退的基线提交。
- 约定分阶段打检查点，每个点都测试通过、信息清晰。
- 回滚类、改写历史类命令由人确认后再执行。
总结
Git 快照是让 Agent 敢干活的安全网：任务前先清理工作区、建分支、确认基线，任务中在每个测试通过的阶段打检查点，出错时分清工作区、暂存区、提交三层，用检出/reset/revert 精确退回——本地未共享可 reset、已推送优先 revert，让 Agent 执行繁琐命令、人掌握不可逆的扳机，你就能在始终可回滚的前提下放手让 Agent 尝试。