Appearance
Git 最小入门
让 AI 改代码之前，先学会给项目拍"存档"——这就是 Git 的最小用途。本页只教 AI 协作最常用的 5 个动作：看状态、看改动、存档、查看记录、回退。不追求精通 Git。
1. 为什么 AI 协作一定要会 Git
AI 修改代码最让人担心的是"改坏了怎么办"。Git 给你三样东西：
- Diff：精确看到 AI 改了哪些文件、哪些行——不靠 AI 自述，自己核对（质量门 G0 的核心要求）。
- 回退：改坏了能一键回到修改前，不用手动恢复代码。
- 记录：每次修改有存档点，出了新问题能对照"上一次好的版本"找差异。
本站的受控式 AI 开发方法和质量门都要求"能看 Diff、能回退"，所以 Git 是前提。
2. 最小命令集
在 Visual Studio 里操作 Git 有图形界面（团队资源管理器/Git 更改窗口），命令行的概念完全一样。以下是命令对照：
| 动作 | 命令 | 干什么 |
|---|---|---|
| 看当前状态 | git status | 哪些文件被改了、新增了、删了 |
| 看具体改动 | git diff | 逐行显示未存档的修改内容 |
| 存档一次 | git add 文件名 然后 git commit -m "说明" | 把当前改动固定成一个存档点 |
| 查看存档记录 | git log --oneline | 列出历史存档点 |
| 查看某次存档改了啥 | git show 存档号 | 显示该次存档的完整 diff |
一次一个目标地提交：每次让 AI 改完一个功能点，检查 Diff 没问题，就提交一次，说明写清楚"改了什么、为什么"。这比攒到最后一次性提交更容易排查。
3. 项目接入 Git：两种方式
- 新项目：Visual Studio 创建项目时勾选"放入 Git 源代码管理"，或之后在"Git 更改"窗口点"创建 Git 存储库"。先在本地建库就够了，不必急着推送到远程。
- 已有项目：直接进入项目文件夹运行
git init，然后第一次提交（git add .+git commit -m "初始版本"）。改代码前先提交一次基线，这是 AI 协作最重要的一步。
4. 回退：AI 改坏了怎么办
分三种情况，从简单到复杂：
| 情况 | 做法 | 注意 |
|---|---|---|
| 还没提交，只想放弃当前改动 | 右键文件 → Git 更改 → 撤销更改；或 git checkout -- 文件名 | 只撤销本次未存档改动，已提交的内容不受影响 |
| 已提交，但想整体退回上一个存档 | git revert 存档号（生成一个"反向修改"的新提交） | 推荐用 revert，它保留历史，不丢东西 |
| 改了多个文件，只想恢复其中一个 | git checkout -- 具体文件路径 | 只针对该文件，其他改动保留 |
安全底线：git reset --hard 会永久丢弃未存档的修改，新手不要使用。 回退前如果对当前状态没把握，先把整个项目文件夹复制一份再操作。
对 AI 修改的回退，本站案例有完整演示：电流状态误判与回退（AI 修改引入乱码后，停止叠补丁、回退本次改动）。回退后要重新构建并做回归验证，确认回到了可用状态。
5. 让 AI 帮你用 Git
- 看 Diff：让 AI "解释这次 diff 改了哪些文件、每处改动的目的，并指出计划外改动"——但要自己核对 AI 的总结，对照
git diff原文。 - 写提交说明：让 AI 根据 diff 生成提交说明，自己确认后使用。
- 找回归源：功能坏了，让 AI "对比这次提交与上一个提交的 diff，找出可能导致回归的改动"。
记住：AI 可以解释，但确认与回退的决定权在你。
6. 别慌，常见情况
| 现象 | 原因 | 处理 |
|---|---|---|
git status 显示一堆没见过的文件 | 可能是构建产物（bin/obj） | 项目里建一个 .gitignore 忽略它们，问 AI 帮你生成 |
| 提示"不是 Git 仓库" | 没在项目根目录或没 init | 确认当前目录再 init |
| 想不起来改了什么 | — | 养成"改前提交、改后提交"的习惯 |
下一步
掌握了 Diff 与回退，就可以安全地让 AI 参与修改了。