深色模式
3.7 每完成一步就存档：实战中的 Git 安全带
第二章已经讲过 Git 为什么是 Vibe Coding 的“后悔药”。
这一篇不再科普概念，也不要求老师照着命令表逐条手敲。
我们只练一件更符合本书目标的事：
text
把 Git 操作交给 Coding Agent，
把确认权留在老师手里。在 3.5 的表单项目中，我们准备好了静态 HTML 和 PRD；在 3.6 的机房排座项目中，我们完成了一次小改造。接下来，无论是初始化仓库、生成 .gitignore、建立存档、推送 Gitee，还是出问题后回到可用版本，都可以让 VS Code、Trae、Qoder 等 IDE 里的 Agent 帮我们完成。
老师不必背下所有 Git 命令，但要始终守住一个顺序：
text
Agent 先检查并解释
-> 老师确认
-> Agent 再执行
-> Agent 报告结果本篇虽然放在第三章最后，这套流程实际应该从 Agent 第一次修改 3.5、3.6 的项目之前就开始使用。
操作交给 Agent，决定留给老师
Coding Agent 可以在项目终端中执行 Git 命令，也能读取文件变化和提交历史。这意味着老师没有必要为了存一次档，先变成 Git 命令高手。
但“交给 Agent 操作”不等于“让 Agent 自己决定”。
| 老师负责什么 | Agent 负责什么 |
|---|---|
| 说明这次要保存哪个成果 | 检查项目是否已有 Git |
| 确认页面或功能已经通过验收 | 检查当前分支、历史和未提交改动 |
| 判断哪些文件和数据不能上传 | 生成或检查 .gitignore |
| 确认提交信息是否能看懂 | 解释差异并完成 git add、git commit |
| 决定是否连接 Gitee | 检查远程仓库和实际分支后完成推送 |
| 确认是否允许回退 | 分析方案、说明影响并执行已确认的方案 |
最关键的边界是：提交、推送和回退之前，Agent 都必须先说明准备做什么。
第一次先让 Agent 做全面检查
用 IDE 打开整个项目文件夹，然后把下面这段话发给 Agent：
text
请作为这个项目的 Git 助手，先只做检查，不要修改文件，也不要执行提交或回退。
请检查并用中文告诉我：
1. 当前目录是否已经是 Git 仓库。
2. 当前分支叫什么，最近几个提交分别做了什么。
3. 当前有没有新增、修改或删除但尚未提交的文件。
4. 是否已经配置远程仓库，远程地址是什么。
5. 是否已有 .gitignore，它是否适合当前项目。
6. 是否发现密钥、环境变量、数据库或真实学生数据可能被提交。
最后告诉我下一步建议，但在我确认之前不要执行任何修改。Agent 的检查结果会把项目分成两种情况。
- 3.5 自己创建的
HTML + PRD文件夹，通常还没有 Git，需要由 Agent 初始化。 - 3.6 从 Gitee 克隆的排座系统，通常已经带有 Git 历史，只需要检查现状，不能重复初始化。
老师不需要自己判断应该输入哪条命令。先让 Agent 识别项目来源，再决定下一步。
自建项目：让 Agent 初始化并生成 .gitignore
以 3.5 的表单项目为例，页面和 PRD.md 已经准备好。第一次存档前，可以继续对 Agent 说：
text
这个项目是我自己创建的，目前准备建立第一个 Git 存档。
如果确认当前目录还不是 Git 仓库，请：
1. 阅读项目目录和配置，判断使用了哪些技术。
2. 先提出 .gitignore 方案，说明准备排除哪些文件以及原因。
3. 重点排除依赖目录、环境变量、账号密钥、构建产物、日志、缓存、临时文件，以及包含真实学生信息的数据库或导出文件。
4. 不要覆盖已有规则，不要提交任何文件。
先把检查结果和方案告诉我，等我确认后再执行初始化和修改 .gitignore。.gitignore 完全可以交给 Agent 根据 Node.js、Python 或项目框架生成，不需要老师从空白文件开始手写。
不过老师还要检查 Agent 的说明中是否明确排除了：
.env这类账号、数据库地址和密钥文件。- 依赖目录、构建产物、日志和缓存。
- 真实学生姓名、学号、成绩对应的数据库或导出文件。
- 不准备公开的学校内部配置。
确认方案没有问题后，再回复：
text
我已确认 .gitignore 方案。请执行初始化并创建或补充 .gitignore。
完成后重新检查项目状态，告诉我：
1. 实际修改了什么。
2. 哪些文件会被 Git 管理。
3. 哪些文件已经被排除。
4. 是否仍有敏感文件风险。
这一步先不要提交。此时 Agent 会在背后完成 git init 和 .gitignore 的创建或补充。老师只需要看懂它最后的中文报告。
克隆项目：让 Agent 沿用原来的仓库
3.6 的机房排座项目如果是从 Gitee 克隆的，通常已经有仓库、历史和远程地址。不要让 Agent 再次执行 git init。
可以这样要求：
text
这个项目来自 Gitee。请沿用现有 Git 仓库，不要重新初始化，也不要改写原有历史。
请检查当前分支、最近提交、远程仓库和未提交改动。
如果状态不干净，请按文件说明这些改动可能来自哪里。
如果 .gitignore 需要补充，请先提出方案，不要直接覆盖。
在我确认之前，不要提交、推送或回退。如果 Agent 发现项目已经存在未提交改动，就先弄清来源。不要把旧改动和这次新任务混在同一个存档里。
第一个存档也让 Agent 完成
初始化和 .gitignore 确认后，先建立一个修改前的可回退基线。
对表单项目，这个基线可以是“静态 HTML 能打开，PRD 已确认”；对从 Gitee 克隆且状态干净的排座项目，原仓库最新提交已经是基线，不需要制造空提交。
表单项目完成验收后，可以发给 Agent：
text
我已经确认静态 HTML 能正常打开，PRD 中的数据字段、统计指标和暂不实现的功能也已经确认。
请先检查当前 Git 差异，然后用中文说明：
1. 准备纳入本次存档的文件。
2. 每个文件为什么应该提交。
3. 哪些文件会被排除。
4. 是否存在密钥、临时文件、数据库或真实学生数据。
5. 建议使用什么中文提交信息。
只做检查和说明，等我确认后再提交。不要让 Agent 看到一句“提交一下”就机械地把所有文件都加入。它需要先检查差异，并说明实际准备保存的范围。
确认后，老师只需回复：
text
验收通过，提交范围和提交信息已经确认。
请完成本次 Git 提交，并在完成后告诉我提交结果和提交编号。
不要推送到远程仓库。Agent 会自行完成 git add 和 git commit。老师不必手敲命令，但能清楚知道这次保存了什么，以及以后可以回到哪个节点。
每完成一个小功能，就重复同一套对话
Git 不是项目最后才做的一次备份。后续每完成一个小功能，都可以重复下面三步。
第一步：修改前让 Agent 检查
text
在开始本次修改前，请先检查 Git 状态。
如果有未提交改动，先按文件解释，不要开始写代码。
如果状态适合继续，请告诉我当前可回退基线是什么。
本次只处理一个功能点，不要顺手重构无关内容。第二步：老师完成真实验收
Agent 完成修改后，老师用模拟数据验证页面、接口和数据是否符合预期。不能因为 Agent 说“已经完成”就直接提交。
适合保存的节点包括：
| 项目 | 可以保存的节点 |
|---|---|
| 表单项目 | HTML + PRD 基线、后端提交成功、数据保存成功、统计看板可用 |
| 排座项目 | 原仓库基线、名单提示改造通过、布局编辑可用、排座操作可用、投屏页面可用 |
第三步：让 Agent 解释并提交
text
我已经使用模拟数据完成验收，本次功能可以正常使用。
请先检查 Git 差异并用中文报告：
1. 修改了哪些文件，每个文件的改动目的是什么。
2. 有没有超出本次需求的改动。
3. 有没有不应提交的临时文件、密钥、数据库或真实数据。
4. 后续还应重点回归测试哪些功能。
5. 建议使用什么中文提交信息。
在我确认之前不要提交。老师确认报告和提交范围后，再让 Agent 执行提交。这样每次存档都对应一个已经验收的小成果，而不是一团说不清的混合改动。
需要多台电脑时，再让 Agent 连接 Gitee
如果项目只在一台电脑上使用，本地 Git 已经可以保存历史。需要在办公室、机房和家里多台电脑间同步，或者需要与同事协作时，再考虑 Gitee。
先在 Gitee 创建仓库。校园项目建议默认设为私有仓库，并确保项目中不包含真实学生数据、账号、密钥和数据库。
得到仓库地址后，把地址交给 Agent：
text
我准备把当前项目连接到 Gitee，用于私有备份和多设备同步。
远程仓库地址是：这里填写实际地址
请先检查：
1. 当前是否已经存在远程仓库，避免重复配置。
2. 当前实际分支名是什么，不要默认写成 main。
3. 当前是否有未提交改动。
4. 即将推送的历史中是否可能包含密钥、真实学生数据或数据库文件。
先说明准备执行的操作和风险，等我确认后再连接和推送。登录、验证码或凭据确认可能仍需要老师在界面中完成。不要把账号密码或访问令牌直接发进对话，也不要把凭据写进项目文件。
远程仓库配置完成后，后续操作就可以更简单。只要同时满足下面三个条件：
- 功能已经使用模拟数据验收通过。
- Agent 已经解释本次改动，老师也确认了提交范围。
- 项目已经连接远程仓库，Agent 知道实际远端分支。
老师就可以直接输入：
text
提交到git，并推送到远端分支。Agent 会完成本地提交并推送到当前项目对应的远端分支。首次连接 Gitee，或者提交范围还没有确认时，不要跳过前面的检查步骤直接使用这句口令。
项目改坏后，也先让 Agent 分析回退方案
回退同样可以交给 Agent，但不能只说一句“帮我恢复”，更不能授权它直接使用会丢弃改动的强力命令。
先发出诊断请求：
text
当前项目修改后出现问题。请先只检查，不要执行任何回退。
请用中文说明：
1. 当前有哪些未提交改动。
2. 最近几个提交分别对应什么可用节点。
3. 问题可能涉及哪些文件。
4. 可以只恢复某个文件，还是需要撤销某次提交。
5. 每种方案会保留什么、丢失什么。
6. 你建议采用哪个风险更小的方案。
在我明确确认之前，不要执行回退，也不要删除任何文件。老师确认目标和影响后，再让 Agent 执行选定方案，并要求它重新报告状态。
回退确认权不能交出去
不要允许 Agent 未经确认执行 git reset --hard 等会直接丢弃改动的操作。即使 Agent 建议回退，也必须先说明将失去哪些内容，并得到老师明确确认。
把这段要求固定在每次改造里
以后每次让 Coding Agent 改项目，都可以在任务末尾附上：
text
Git 管理也由你协助完成，但必须遵守以下规则：
1. 修改前先检查仓库状态和当前可回退基线。
2. 不要把密钥、环境变量、数据库和真实学生数据加入提交。
3. 修改后先报告差异和验收重点，不要自动提交。
4. 等我完成验收并明确确认后，再执行提交。
5. 提交后报告提交信息、提交编号和当前状态。
6. 未经我确认，不要推送远程仓库或执行任何回退。这就是 3.7 真正要建立的能力：老师不用亲自完成每条 Git 操作，但要会指挥 Agent、检查报告并守住最终确认权。
到这里，第三章的实战链路就完整了：
text
老师提出一个小需求
-> Agent 修改项目
-> 老师使用模拟数据验收
-> Agent 解释 Git 差异
-> 老师确认
-> Agent 保存可回退节点下一章，我们继续进入校园部署、内网适配、白名单和连通性验证。项目在往真实环境走之前，先让 Agent 把每个已经可用的阶段稳稳保存下来。
用流程图回看 Agent Git 管理
flowchart TD
A[老师提出 Git 任务] --> B[Agent 检查状态和风险]
B --> C[Agent 用中文说明方案]
C --> D{老师是否确认}
D -- 否 --> B
D -- 是 --> E[Agent 执行 Git 操作]
E --> F[Agent 报告结果和回退点]
封面