Git：给代码设置可解释的存档点
Git 记录每一次有意义的变化，使 AI 生成的改动也能被比较、审查和恢复。
- 每个稳定节点都有可说明、可比较、可恢复的版本。
- 仓库、工作区、暂存区与提交
- 连续完成两次小提交，并比较它们之间具体改变了什么。
- 完成 3.2「从单文件到项目结构」
FOUNDATION
必须理解
Git 记录每一次有意义的变化，使 AI 生成的改动也能被比较、审查和恢复。
Git 是版本控制系统（Version Control System，VCS），它把一组有意义的文件变化保存成可比较的快照。AI 产生改动速度很快，Git 是你审查和恢复这些改动的安全网。
Git 像带说明的游戏存档：工作区是正在玩的状态，暂存区是准备放进本次存档的变化，提交是写好说明后保存的稳定节点。
任务应用先提交“建立静态页面”，再提交“支持添加任务”。如果第二步出错，可以比较两个提交，而不是依赖 final-final.zip。
仓库、工作区、暂存区与提交
一个被 Git 管理的项目叫仓库。你正在改的文件处于工作区，准备放进下一次存档的内容在暂存区，真正的提交则会记住这次变化、时间和说明。
基础概念
Git 仓库是包含版本历史的项目；工作区是当前文件状态，暂存区是下一次提交的候选快照，提交是带说明、作者和父版本的永久历史节点。
进一步理解
编辑文件只改变工作区；`git add` 把指定变化复制到暂存区；`git commit` 根据暂存区创建新版本。未暂存的其他修改不会自动进入该提交。
这种分层允许把同时存在的修改拆成有意义的小提交。提交后工作区仍可能有未保存到历史的变化，需要再次查看状态。
修改页面结构和文案后，可以只暂存结构文件建立一次提交，再将文案调整作为下一次独立提交。
保存文件只写入磁盘，不等于 Git 提交；`git add` 也没有创建历史版本，它只是准备下一次快照。
这一小节记住：工作区负责编辑，暂存区负责选择，提交负责形成可解释历史。
git status、diff、add、commit 的关系
status 先告诉你现在乱不乱，diff 再给你看具体改了什么，add 选择本次要保存的内容，commit 才真正建立一个版本。这个顺序比一上来就提交安全得多。
基础概念
`git status` 概括当前状态，`git diff` 展示具体差异，`git add` 选择变化，`git commit` 建立版本。这是一条从观察到保存的证据链。
进一步理解
提交前先看未暂存差异，再看 `--staged` 差异，可以发现调试日志、秘密或无关文件是否被误选。提交说明应描述这组变化实现的意图。
小而完整的提交更容易审查和回退。所谓“小”不是行数越少越好，而是只表达一个能够独立说明的变化。
新增任务输入与列表可作为一个功能提交；顺手进行的大面积格式化应分开，否则审查者难以看到真正逻辑。
提交成功不说明测试通过，也不说明远端已有备份；测试、commit 和 push 是不同动作。
这一小节记住：先看状态与差异，确认范围后再创建提交。
.gitignore 与敏感文件、生成文件
.gitignore 可以让依赖、构建产物和本地秘密不再被新加入 Git。不过一个文件如果以前已经提交过，后来写进 ignore 并不会自动从历史里消失。
基础概念
`.gitignore` 告诉 Git 哪些尚未跟踪的路径通常不应加入版本历史，例如依赖目录、构建产物、本地配置和秘密文件。
进一步理解
依赖与构建结果应由清单和命令重建，提交它们会放大仓库并制造平台差异。`.env` 等秘密文件不能进入共享历史，应提供不含真实值的示例。
忽略规则不会删除已被跟踪的文件，更不会擦除历史中的秘密。一旦凭证提交过，需要立刻轮换，并按安全流程清理暴露。
任务应用提交 package.json 与锁文件，但忽略 node_modules、构建目录和 `.env.local`，同时保留 `.env.example` 说明需要哪些变量。
`.gitignore` 不是访问控制，也不是秘密保险箱；它只影响 Git 默认选择文件的行为。
这一小节记住：能重建的产物和本地秘密通常不进仓库，但清单与迁移必须进入。
- 当前目录已经是 Git 仓库，并且三个目标文件确实属于本次功能。
- 先确认没有密码、令牌或无关用户改动准备被暂存。
git status
git diff
git add index.html style.css script.js
git diff --staged
git commit -m "feat: add task input and list"先观察，再选择，再复核暂存内容，最后创建有意义的提交。
- status 给出整体状态，diff 展示尚未暂存的具体内容。
- add 只选择明确列出的三个文件，避免顺手收入其他变化。
- diff --staged 复核下一次提交的准确内容，commit 才建立历史节点。
提交成功后，日志中出现说明清楚的新版本；再次运行 status 时，本次三个文件不再显示为未提交，但其他未选择改动仍被保留。
AI COLLABORATION
AI 如何参与
每次让 AI 改动前先查看状态和差异，完成后要求它解释 diff，而不是只说“已经好了”。
推荐协作顺序
- 1
先把 git status 和 diff 发给 AI，让它解释每个文件发生了什么。
- 2
让它按功能拆提交，并说明为什么这些文件应该放在一起。
- 3
提交前再看 staged diff，确认 AI 没漏掉或混入无关内容。
我正在学习 Git。请根据我随后提供的 git status 和 git diff，帮我把改动拆成小提交。先解释每个文件为什么属于某个提交，再给出安全命令。禁止使用 reset --hard、force push、批量删除和覆盖未提交改动。
AI 应基于真实差异建议提交边界，不应凭空假设文件内容或直接执行破坏性回退。
人工检查清单
- 确认暂存范围只包含预期文件，提交中没有 .env、密钥、依赖目录或无关个人文件。
- 要求 AI 按文件解释暂存差异为何属于本次提交，并指出任何可疑秘密或生成物。
- 提交后重新检查状态并运行相关验证，确认历史节点与真实可用状态一致。
COMMON TRAPS
常见误区
错误不是需要隐藏的失败，而是帮助你看清系统边界的证据。下面三类问题在 AI 辅助学习中最常出现。
改了一周才提交一次
- 你会看到
- 页面、接口和文案全混在同一个巨大提交里。
- 为什么发生
- 大提交混合多个意图，审查者难以识别错误，回退时也会被迫撤销本来正确的部分。
- 怎样纠正
- 完成一个可说明的小目标就提交，提交信息写清改变带来的结果。
git add . 之后不检查
- 你会看到
- 日志、临时文件甚至 .env 一起进入暂存区。
- 为什么发生
- 凭证进入提交后会被复制到历史和远端，仅删除当前文件不能让已泄露的值失效。
- 怎样纠正
- 用 diff --staged 复核，敏感或生成文件先从暂存区移除。
出问题就使用强制回退
- 你会看到
- 为了恢复一个文件，顺手丢掉了其它尚未提交的修改。
- 为什么发生
- 破坏性回退会同时丢掉尚未保存的用户修改；没有先看状态和差异就无法确认损失范围。
- 怎样纠正
- 先看 status 和 diff，明确要恢复的单个目标，再选择可恢复的方法。
HANDS-ON
动手任务
连续完成两次小提交，并比较它们之间具体改变了什么。
- 完成 3.2「从单文件到项目结构」
跟着做
- 01
在静态任务应用目录初始化 Git 仓库。
- 02
运行 status，观察未跟踪文件并解释含义。
- 03
添加页面文件，查看暂存差异并创建第一次提交。
- 04
增加空输入校验，再次查看差异并单独提交。
- 05
查看日志，对比两次提交包含的文件变化。
每个稳定节点都有可说明、可比较、可恢复的版本。
创建 .gitignore 忽略一个本地练习配置文件，并验证它不会进入暂存区。
离开本课前，自问四件事
- 工作区、暂存区和提交之间的数据怎样移动？
- 为什么提交前要分别查看未暂存与已暂存差异？
- 哪些文件应被忽略，哪些用于重建环境的清单必须提交？
- 秘密曾被提交后，为什么仅加入 .gitignore 还不够？
确认完成后，会同步更新学习中心的课程学习进度。