版本控制

这一课你将能做到

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 总结改动：

基于 git diff，生成符合 conventional commits 规范的提交信息：
- 格式：type(scope): 一句话描述
- type 从 feat/fix/refactor/docs/test/chore 中选
- 如果改动大，列出多个 commit，每个 commit 只包含一个逻辑变更

AI 会给你：

feat(article): 新增文章置顶功能
- Article 表加 is_top 字段（迁移 SQL）
- 列表查询按 is_top 降序排列
- PUT /articles/{id}/top 接口

test(article): 置顶功能单元测试

步骤 5：用 AI 做 Code Review 前置检查

推送到远程前，让 AI 先自查：

检查当前分支的 git diff，找出：
1. 可能的安全问题（SQL 注入、XSS、硬编码密钥）
2. 明显的逻辑错误
3. 不符合项目约定的地方（返回格式、命名、分层）
4. 缺失的边界条件处理

这不能替代人工 Review，但能过滤掉 80% 的低级问题，让人工 Review 聚焦在业务逻辑上。

步骤 6：生成变更日志

发版前让 AI 生成 CHANGELOG：

基于 v1.2.0 到 HEAD 的所有 commit，生成 CHANGELOG.md 草稿：
- 按 Added / Changed / Fixed / Deprecated / Removed / Security 分组
- 每条一行，包含 commit hash 前 7 位

讲清楚要点

1. 「AI 改动前先 commit」是铁律：没有干净的保存点，AI 的每次大改都是赌博。
2. 原子提交是对抗 AI 代码量爆炸的唯一方法：AI 一次改十文件，你分四次 commit，Review 和回滚都按层进行。
3. 实验分支隔离架构级改动：AI 做架构迁移时开实验分支，验证通过再合并，不通过直接丢弃，主分支永远干净。
4. 提交信息要人工把关：AI 生成的提交信息可能遗漏关键上下文（比如「这个改动是为了修线上 bug #1234」），关键信息你补。
5. AI 前置 Review 过滤低级问题：安全、约定、边界条件让 AI 先扫一遍，人工 Review 聚焦业务逻辑和架构。

你可能会懵的地方

• AI 生成的代码需要 Code Review 吗？ 需要，而且比人写的更需要。人写的代码有「作者理解」做背书，AI 生成的代码只有「看起来对」。所有 AI 生成代码必须走和人写代码相同的 Review 流程。

• AI 改动量太大，Review 不过来怎么办？ 原子提交是解法。AI 一次改十文件，你分四次 commit，每次 Review 只看一层。如果 AI 的改动没法拆成原子提交，说明改动面太大，应该让 AI 分阶段生成。

• AI 能直接 push 到远程吗？ 不建议。git push 保持人工操作。AI 可以帮你生成提交信息、做本地检查，但「推送到远程」这个动作必须人来执行，防止 AI 把未验证的代码推上去。

• AI 生成的提交信息太简略怎么办？ 在提示词里加约束：「提交信息要包含改动原因，不只是改动内容。比如不说『修改了 UserService』，而说『修复用户注册时邮箱重复校验失效的问题』」。

• 多人同时用 AI 改同一个文件，冲突爆炸怎么办？ 更小的功能分支、更频繁的 rebase/merge、更清晰的模块边界。AI 让个人产出速度变快，但协作的瓶颈还在「人对同一块代码的理解」上。

错法对照

错法	问题	正解
AI 改完直接 commit 所有文件	改动混在一起，无法拆分 Review	原子提交，按层/按功能拆分
工作区不干净就让 AI 改	手改和 AI 改混杂，无法回滚	先 commit 或 stash，再让 AI 动手
AI 直接 push 到远程	未验证代码进远程仓库	push 保持人工操作
提交信息全是「fix」「update」	历史不可读，无法追溯	conventional commits + AI 生成草稿+人工补充
架构级改动直接在 main 上做	改乱了无法收场	实验分支隔离，验证后合并

卡点急救

1. AI 改乱了，想回到改动前：git checkout -- . 丢弃工作区所有改动，回到最后一次 commit。这就是「先 commit」的价值。
2. AI 的改动和别人的改动冲突了：git rebase 或 git merge 解决冲突时，把冲突区域贴给 AI：「这两个版本各自想干什么？合并时要注意什么？」AI 能帮你理解冲突双方的意图。
3. 历史太乱想整理：让 AI 帮你生成 git rebase -i 的 squash 计划，或生成「把最近 10 个 commit 整理成 3 个原子提交」的操作步骤。

面试常问

• AI 生成大量代码时，Git 工作流怎么调整？ 高分回答：三个调整——「AI 改动前先 commit」的铁律、原子提交拆分 AI 的大量输出、实验分支隔离架构级改动。核心思路是「用 Git 的安全网对冲 AI 的不确定性」。

• AI 生成的提交信息质量怎么保证？ AI 生成草稿+人工补充关键上下文（关联的 issue、改动原因）；团队约定 conventional commits 格式；CI 里用 commitlint 校验格式。

• 多人团队都用 AI 辅助开发，代码冲突会加剧吗？ 会，因为个人产出速度变快，并行改动同一区域的概率增加。解法：更小的功能分支、更频繁的同步、更清晰的模块边界，以及 AI 辅助的冲突分析。

自测三问

1. 为什么「AI 改动前先 commit」是 AI 协作的第一铁律？
2. 原子提交在 AI 协作场景下解决什么问题？
3. AI 做架构级重构时，应该用什么分支策略？

小结一句话

Git 是 AI 时代的后悔药和保险丝——原子提交管 Review，实验分支管风险，人工 push 管底线。

延伸

• Conventional Commits 规范
• Git 官方文档
• 下一课：测试——AI 写测试的纪律与边界。