版本控制

这一课你将能做到

1. 用原子提交（atomic commit）策略管理 AI 生成的大量代码
2. 设计 AI 协作场景下的分支模型（功能分支 + AI 实验分支）
3. 让 AI 帮你写规范的提交信息、生成变更日志、做 Code Review 前置检查

为什么要学

AI 时代 Git 的重要性不降反升。原因很简单：AI 改代码的速度是人写的十倍，如果没有版本控制兜底，一次 AI 的「自由发挥」就能毁掉你三天的工作。

人话：Git 是 AI 时代的「后悔药」和「保险丝」。后悔药——AI 改乱了，git checkout -- . 一秒回到从前；保险丝——AI 每次大改前你先 commit，改坏了最多丢掉这十分钟，不会丢掉整个下午。

真实项目中，AI 协作的 Git 策略要解决三个新问题：AI 生成的代码量大涨怎么审、AI 的实验性改动怎么隔离、提交信息怎么保持可读（不能全是「fix」「update」「change」）。

先建立图像

AI 协作的 Git 安全网：
┌─────────────────────────────────────────┐
│ 工作区干净 ←→ AI 改动 ←→ 暂存区 ←→ 提交  │
│      ↑                              ↓   │
│   git checkout -- .            git commit
│   （后悔药）                    （保险丝） │
└─────────────────────────────────────────┘

分支模型：
main ─────●────────●────────●──→
           \      / \      /
feature ────●──●    ●──●──
                \
ai-experiment ──●──●（AI 实验，验证后合并或丢弃）

跟着做

步骤 1：建立「AI 改动前先 commit」的肌肉记忆

这是 AI 协作的第一铁律。每次让 AI 干活前：

git status                    # 确认工作区干净
git add .
git commit -m "chore: AI 改动前的保存点"

如果工作区不干净，先把手头的改动提交或 stash，再让 AI 动手。否则 AI 的改动和你的改动混在一起，回滚时无法分离。

步骤 2：用原子提交管理 AI 的大量输出

AI 一次可能生成/修改十几个文件。不要一次性 commit 所有改动，拆成原子提交：

# AI 生成了：ArticleController.java + ArticleService.java + ArticleMapper.xml + 测试

# 原子提交 1：接口层
git add src/main/java/com/example/controller/ArticleController.java
git commit -m "feat(article): 新增文章分页列表接口"

# 原子提交 2：业务层
git add src/main/java/com/example/service/ArticleService.java
git commit -m "feat(article): 实现文章列表业务逻辑"

# 原子提交 3：数据层
git add src/main/resources/mapper/ArticleMapper.xml
git commit -m "feat(article): 文章列表 SQL 查询"

# 原子提交 4：测试
git add src/test/java/com/example/service/ArticleServiceTest.java
git commit -m "test(article): 文章列表单元测试"

原子提交的好处：Code Review 时逐 commit 审，每个 commit 只干一件事，出问题容易定位到具体哪一层。

步骤 3：用分支隔离 AI 的实验性改动

AI 做架构级重构（比如「把 MyBatis 换成 JPA」）时，开实验分支：

git checkout -b ai-experiment/mybatis-to-jpa
# 让 AI 在这个分支上放手改
# 验证 OK 后合并回 feature 分支
# 验证不 OK，直接丢弃：git branch -D ai-experiment/mybatis-to-jpa

步骤 4：让 AI 生成规范的提交信息

提交前让 AI 总结改动：