5.1.6 版本管理最佳实践
学会了工具的基本操作，接下来是一些让版本管理更有效的技巧。
Commit 信息怎么写
每次 Commit 都需要写一句描述。好的描述能让你快速找到需要的版本。
好的写法
✅ "添加任务删除功能"
✅ "修复刷新后数据丢失的问题"
✅ "调整按钮颜色为蓝色"
✅ "第四章完成版"
✅ "准备添加深色模式前的备份"特点：
- 说清楚做了什么
- 一眼就能看懂
不好的写法
❌ "修改了一些东西"
❌ "update"
❌ "fix"
❌ "..."
❌ "1"问题：
- 看不出做了什么
- 以后找版本时完全没帮助
简单原则
用一句话描述"这次改动做了什么"。
不需要写得很正式，只要自己以后能看懂就行。
多久 Commit 一次
原则：完成一个小功能就 Commit。
| 做法 | 优缺点 |
|---|---|
| 每改一行就 Commit | ❌ 太频繁，历史太乱 |
| 做完一个功能就 Commit | ✅ 推荐，粒度合适 |
| 写了一大堆再 Commit | ❌ 出问题难回退，找不到问题点 |
推荐的 Commit 时机
- 添加了一个新功能
- 修复了一个问题
- 调整了样式/布局
- 重构了代码结构
- 准备下班/休息
不要等到"完美"了再 Commit。半成品也可以 Commit，反正随时可以继续改。
什么文件应该/不应该提交
有些文件应该纳入版本管理，有些不应该。
应该提交的文件
- 你写的代码（HTML、CSS、JavaScript 等）
- 项目配置文件
- 文档和说明
不应该提交的文件
| 类型 | 例子 | 为什么 |
|---|---|---|
| 依赖包文件夹 | node_modules/ | 太大，可以重新安装 |
| 环境配置 | .env | 可能包含密码等敏感信息 |
| 系统文件 | .DS_Store（Mac） | 与项目无关 |
| 编译产物 | dist/、build/ | 可以重新生成 |
使用 .gitignore 文件
在项目根目录创建一个名为 .gitignore 的文件，写入要忽略的文件/文件夹：
# 依赖
node_modules/
# 环境配置
.env
.env.local
# 系统文件
.DS_Store
Thumbs.db
# 编译产物
dist/
build/GitHub Desktop 会自动忽略这些文件，不会把它们纳入版本管理。
提示
如果你用的是纯 HTML/CSS/JS 的简单项目（比如待办清单），暂时不需要担心 .gitignore。这个文件在项目变复杂后才会用到。
三级方案对比与选择
| 方案 | 学习成本 | 可靠性 | 云端备份 | 适合场景 |
|---|---|---|---|---|
| AI IDE 自带历史 | 零 | 中 | 否（网页版除外） | 日常小改动 |
| 手动复制文件夹 | 零 | 高 | 否 | 重要节点备份 |
| GitHub Desktop | 低 | 高 | 是 | 长期项目、想学专业技能 |
推荐组合
最省心的方案：
- 日常依赖 AI IDE 自带历史
- 完成重要功能时手动备份一个文件夹
- 项目完成后考虑上传到 GitHub
想要专业一点：
- 从一开始就用 GitHub Desktop
- 每完成一个功能就 Commit
- 每天结束时 Push 到云端
本节检查清单
完成本节学习后，确认你掌握了以下内容：
- [ ] 知道在哪里找到 AI IDE 的历史功能
- [ ] 能够使用历史功能回退到之前的版本
- [ ] 会用手动复制文件夹的方式备份项目
- [ ] 知道什么时候应该保存一个版本
- [ ] （可选）安装了 GitHub Desktop
- [ ] （可选）成功把项目上传到了 GitHub
- [ ] （可选）知道 Commit 信息怎么写
恭喜你
从现在起，你的代码有了"时光机"保护。
不管是 AI IDE 自带的历史，还是手动备份，还是 GitHub Desktop——你已经掌握了保护自己劳动成果的能力。
这意味着：
- 你可以大胆尝试新功能，不怕改崩
- 你可以让 AI 做实验性的改动，不满意就回退
- 你的 2 小时成果不会因为一个小失误而白费
这不是终点，而是新的起点。
接下来，我们要把你的待办清单发布到互联网上，让全世界都能访问。
鼓励
从"代码改崩了就没了"到"随时可以回退"——这是一个重要的思维转变。
你已经比很多初学者更懂得保护自己的成果。继续前进！