#修改检查与恢复

#确认版本管理状态

开始修改前，应先确认当前环境能够使用 Git，并核对项目是否已经纳入版本管理。以下以 Windows 中的“栖迟笔记”项目为例，在 PowerShell 中执行；如果当前处于 Claude Code 会话，可先运行 /exit 返回终端：

cd "C:\Projects\note"
git --version
git rev-parse --show-toplevel
git status

git --version 用于确认 Git 是否可用。如果提示无法识别命令，应先安装 Git，并重新打开终端。Windows 可从 Git 官方下载页面 安装 Git for Windows。

git rev-parse --show-toplevel 用于显示当前所属仓库的根目录，git status 用于查看分支和工作区状态。若显示的仓库根目录是项目的上级目录，应先确认当前项目是否属于该仓库，不宜直接在内部另建仓库。

如果提示 not a git repository，说明当前目录不属于 Git 仓库。对于自行建立、尚未纳入版本管理的练习项目，可在项目根目录执行：

git init

git init 只建立仓库，不会自动保存当前文件的版本。为后续修改建立比较基准，还应先创建一次初始提交。

首次使用 Git 时，如果尚未配置提交者身份，或提交时出现 Author identity unknown，可将以下示例替换为自己的署名和邮箱后执行：

git config user.name "你的署名"
git config user.email "你的邮箱"

这两项设置用于记录提交者身份，不是账户登录，也不会修改 Git 的全局配置。

以“栖迟笔记”当前的四个主要文件为例，先将准备记录的文件加入暂存区，再检查暂存内容：

git add index.html styles.css app.js README.md
git diff --cached

确认内容正确后，建立初始提交：

git commit -m "建立初始版本"
git status

git add 表示选择准备提交的内容，git commit 才会将这些内容保存为一个版本。上述操作均在本地完成，不要求建立 GitHub 仓库，也不会自动上传文件。

已有提交记录的项目无需重复初始化。应先检查现有变更，并按项目流程保存已有工作，再开始新的任务。

初始提交应尽量在交给 Claude Code 修改之前完成。如果修改已经发生，之后建立的首次提交只能记录当前状态，不能自动找回修改前的文件。

#查看实际差异

在已建立 Git 仓库和初始提交的项目中，完成修改后，可运行 /diff 查看工作区变更，也可在编辑器或 Git 工具中检查。具体展示形式和比较范围取决于 Claude Code 版本及当前选择，应先确认正在比较哪个基准。

差异列表可能包含会话开始前已经存在的未提交内容，因此不能将其中全部变更都归因于 Claude Code。开始任务前记录工作区状态，结束后再进行比较，有助于区分本次修改与原有改动。

需要在普通终端中辅助检查时，可执行：

git status --short
git diff
git diff --cached

git status --short 用于查看变更文件及其状态；git diff 查看尚未暂存的已跟踪文件差异；git diff --cached 查看已经暂存、准备提交的差异。新建但尚未跟踪的文件通常显示为 ??，其内容不会直接出现在普通 git diff 中，应另行打开检查。

请结合当前差异，说明本次任务实际修改的内容。

请按文件列出：
1. 修改目的；
2. 主要行为变化；
3. 对原有功能的影响；
4. 已执行的验证及结果。

如无法区分某项改动是否由本次任务产生，请明确标注。
检查结果仅作说明，不额外修改文件。

检查时，应重点关注是否修改了约定范围之外的文件、是否引入新依赖、是否改变公开接口，以及是否通过削弱校验或删除测试来消除报错。界面任务还应检查实际显示与交互，不能仅以构建成功作为最终验收依据。

如果项目尚未使用 Git，仍可检查当前文件、编辑器本地历史或已有备份，但不能将“查看当前内容”表述为已经核对了相对于历史版本的完整差异。

#使用检查点

Claude Code 可记录文件编辑工具产生的变更，并通过检查点回到此前状态。这一机制不要求项目已初始化 Git，也不会自动替代 Git 提交。

运行 /rewind，或在输入框为空时连续按两次 Esc，可打开回退菜单；输入框有文字时，连续按两次 Esc 会先清除草稿。选择历史位置后，可根据实际可用选项恢复代码与对话、仅恢复代码，或仅恢复对话。只有所选位置之后存在已跟踪的文件变更时，才会出现相应的代码恢复选项。部分菜单还提供区段摘要选项。

应先确认希望改变的是文件状态还是对话状态，避免把“仅恢复对话”误认为已撤销代码。检查点恢复也不等于切换 Git 分支或撤销已有提交。

检查点主要覆盖其能够跟踪的文件状态，仅由终端命令、外部程序或部分子代理产生的修改，可能不在主会话检查点的恢复范围内；已被跟踪的文件如果随后又被其他方式修改，回退时也可能一并恢复。因此，恢复前仍应检查是否存在需要保留的后续修改。

数据库写入、远端接口调用和部署等外部影响，不能依赖检查点撤销。

#保留版本记录

检查点适合会话内的快速调整，Git 适合长期保存版本、比较差异和开展协作。开始较大修改前，应先确认已有工作已妥善保存；形成可用阶段成果后，再检查差异、完成必要验证，并按项目流程选择文件进行提交。

提交成功只表示文件内容已记录为一个版本，不代表程序运行或测试已经通过。在普通终端中，可使用以下命令查看版本记录、当前分支和工作区状态：

git log --oneline -5
git branch --show-current
git status --short

采用检查点或 Git 恢复后，都应重新检查当前文件和运行结果；使用 Git 的项目还应核对分支与工作区状态，确认预期状态已经恢复。随后继续提出任务时，应说明采用的基准，避免沿用已撤销方案。

请以当前恢复后的文件为基准继续处理。

保留目标：{已经确认的需求}。
停止沿用：{已撤销方案及对应假设}。
下一步仅完成：{具体事项}。

执行前，请先核对相关文件的当前状态，并说明此次修改范围。