Git：给代码设置可解释的存档点
Git 把有意义的改动保存成可比较的记录。每次提交前先看状态和差异，才能知道自己准备留下什么。
- 完成两次范围清楚的提交，并能从 diff 解释每次提交改变了哪些文件和行为。
- 仓库、工作区、暂存区与提交
- 实现Git：给代码设置可解释的存档点后，应当完成两次范围清楚的提交，并能从 diff 解释每次提交改变了哪些文件和行为，并保留diff、提交记录、远端历史和公开页面作为可重复检查的依据。
- 完成 3.5「从单文件到清楚的项目结构」
FOUNDATION
必须理解
Git 是版本控制系统（Version Control System，VCS），它把一组有意义的文件变化保存成可比较的快照。AI 产生改动速度很快，Git 是你审查和恢复这些改动的安全网。
本课依次讲清仓库、工作区、暂存区与提交、git status、diff、add、commit 的关系和.gitignore 与敏感文件、生成文件，最后通过“查看日志，对比两次提交包含的文件变化”检查学习结果。
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"阅读Git：给代码设置可解释的存档点示例时，先观察，再选择，再复核暂存内容，最后创建有意义的提交。
- status 给出整体状态，diff 展示尚未暂存的具体内容。
- add 只选择明确列出的三个文件，避免顺手收入其他变化。
- diff --staged 复核下一次提交的准确内容，commit 才建立历史节点。
提交成功后，日志中出现说明清楚的新版本；再次运行 status 时，本次三个文件不再显示为未提交，但其他未选择改动仍被保留。
AI COLLABORATION
AI 如何参与
在Git：给代码设置可解释的存档点这一课，AI 负责根据真实材料解释仓库、工作区、暂存区与提交并指出遗漏，学习者负责控制范围、执行修改和核对diff、提交记录、远端历史和公开页面。
推荐协作顺序
- 1
先把 git status 和 diff 发给 AI，让它解释每个文件发生了什么。
- 2
让它按功能拆提交，并说明为什么这些文件应该放在一起。
- 3
提交前再看 staged diff，确认 AI 没漏掉或混入无关内容。
下面是 git status 与 git diff。请只做只读分析，按文件解释改动意图，指出不应提交的敏感或生成文件，并建议怎样分成小提交。不要执行 reset、clean、checkout 或删除命令。
AI 应基于真实差异建议提交边界，不应凭空假设文件内容或直接执行破坏性回退；Git：给代码设置可解释的存档点的人工验收必须回到真实页面、请求、终端、测试或数据结果，不能用 AI 的文字说明代替。
人工检查清单
- 确认暂存范围只包含预期文件，提交中没有 .env、密钥、依赖目录或无关个人文件。
- 要求 AI 按文件解释暂存差异为何属于本次提交，并指出任何可疑秘密或生成物。
- 提交后重新检查状态并运行相关验证，确认历史节点与真实可用状态一致。
COMMON TRAPS
常见误区
下面三类问题会让任务看似完成，却经不起刷新、错误输入或真实环境检查。先看现象，再找原因和修正方法。
把所有改动一次提交
- 你会看到
- 提交同时包含功能、格式和无关文件
- 为什么发生
- 不同目的混在一个提交里，审查和回退时无法只选择需要的部分。
- 怎样纠正
- 按一个可说明的目的选择暂存内容
提交密钥或本地配置
- 你会看到
- 仓库历史中出现凭证
- 为什么发生
- Git 会长期保存历史，即使后来删除文件，旧提交里仍可能找到凭证。
- 怎样纠正
- 提交前检查 diff，并撤销已暴露凭证
遇到问题就破坏性回退
- 你会看到
- 尚未保存的用户改动被覆盖
- 为什么发生
- 未提交改动没有可靠副本，强制覆盖后通常无法从 Git 找回。
- 怎样纠正
- 先查看状态和历史，再选择可恢复操作
HANDS-ON
动手任务
完成两次范围清楚的提交，并能从 diff 解释每次提交改变了哪些文件和行为。
- 完成 3.5「从单文件到清楚的项目结构」
跟着做
- 01
在静态任务应用目录初始化 Git 仓库。
- 02
运行 status，观察未跟踪文件并解释含义。
- 03
添加页面文件，查看暂存差异并创建第一次提交。
- 04
增加空输入校验，再次查看差异并单独提交。
- 05
查看日志，对比两次提交包含的文件变化。
完成两次范围清楚的提交，并能从 diff 解释每次提交改变了哪些文件和行为。
创建 .gitignore 忽略一个本地练习配置文件，并验证它不会进入暂存区。
离开本课前，自问四件事
- 工作区、暂存区和提交之间的数据怎样移动？
- 为什么提交前要分别查看未暂存与已暂存差异？
- 哪些文件应被忽略，哪些用于重建环境的清单必须提交？
- 秘密曾被提交后，为什么仅加入 .gitignore 还不够？
确认完成后，会同步更新学习中心的课程学习进度。