Git 工作流与 AI 协作
AI 开发时代的 Git 使用原则
AI 辅助开发改变了代码的生产方式，但并没有降低版本控制的重要性——恰恰相反，在使用 AI 生成大量代码时，良好的 Git 实践变得更加关键。
原因很简单：AI 生成的代码可能一次性改动数十甚至数百行，如果出现问题，没有清晰的提交历史，回滚和定位问题会变得非常困难。同时，AI 有时会在你未预期的地方"顺手"修改代码，细粒度的提交能帮你快速发现这类行为。
分支策略
推荐的分支模型
main（生产就绪代码）
↑ PR 合并
develop（集成分支）
↑ PR 合并
feature/xxx（功能分支）
↑ 日常 AI 开发工作AI 开发的分支命名约定
为每个规格文档或任务组创建独立分支：
bash
# 按功能命名
git checkout -b feature/user-authentication
git checkout -b feature/order-management
git checkout -b fix/payment-edge-cases
# 可以标注这是 AI 辅助的分支（可选，取决于团队偏好）
git checkout -b feature/user-auth-ai隔离实验性探索
当你不确定某个实现方向时，创建临时分支进行探索：
bash
# 探索分支：不确定这个方向是否可行
git checkout -b explore/graphql-vs-rest
# 实验完成后，择优合并或直接删除
git branch -d explore/graphql-vs-rest频繁的小提交
为什么频繁提交在 AI 开发中更重要
使用 AI 开发时，每次"任务完成"都是一个自然的提交点。养成以下习惯：
- 完成每个任务单元后立即提交（对应任务分解中的每个小任务）
- AI 生成代码后，审查通过才提交（不要积累未审查的代码）
- 重构和功能实现分开提交（便于回溯）
bash
# 每完成一个 AI 任务就提交一次
git add src/models/user.ts
git commit -m "feat: add User model with authentication fields"
git add src/api/auth/register.ts src/api/auth/register.test.ts
git commit -m "feat: implement user registration endpoint with validation"
git add src/api/auth/login.ts
git commit -m "feat: implement JWT-based login endpoint"提交粒度指南
| 提交范围 | 示例 | 建议 |
|---|---|---|
| 单个文件 | 添加一个新组件 | 理想的提交粒度 |
| 2-5 个关联文件 | 接口+实现+测试 | 常见的合理提交 |
| 5-10 个文件 | 完整的功能模块 | 可以接受，需要详细说明 |
| 10 个以上文件 | 考虑是否可以拆分 | 尽量避免 |
AI 辅助的提交信息
提交信息是代码历史的重要组成部分。你可以让 AI 帮你生成规范的提交信息：
提示词模板
请为以下代码变更生成一条符合 Conventional Commits 规范的提交信息。
要求：
- 格式：type(scope): description
- 首行不超过 72 个字符
- 如果需要，添加简短的正文说明主要变更点
- 使用英文
变更内容：
[粘贴 git diff 输出]常用提交类型
feat: 新功能
fix: Bug 修复
refactor: 代码重构（不改变功能）
test: 添加或修改测试
docs: 文档变更
style: 代码格式（不影响逻辑）
perf: 性能优化
chore: 构建流程或辅助工具变更实际示例
bash
# AI 生成代码后的提交示例
git commit -m "feat(auth): implement JWT refresh token rotation
- Add refresh token to User model
- Implement /api/auth/refresh endpoint
- Invalidate old refresh token on use (rotation strategy)
- Add 7-day expiry for refresh tokens"Pull Request 工作流
PR 创建前的自查清单
在创建 PR 之前，完成以下检查（这些检查 AI 可以帮你执行）：
bash
# 1. 确保分支是最新的
git fetch origin
git rebase origin/develop
# 2. 运行完整测试套件
npm test
# 3. 检查类型错误
npm run type-check
# 4. 检查 Lint
npm run lint
# 5. 检查是否有不该提交的文件
git diff --name-only origin/developAI 辅助生成 PR 描述
请为以下 PR 生成一份清晰的描述，包含：
1. 这个 PR 解决了什么问题
2. 主要的技术实现方案
3. 测试了哪些场景
4. 审查者需要重点关注的地方
分支名称：feature/user-authentication
提交记录：[粘贴 git log --oneline 输出]
主要变更文件：[列出关键文件]PR 模板（集成 AI 开发注意事项）
markdown
## 变更描述
<!-- 这个 PR 做了什么，解决了什么问题 -->
## 实现方案
<!-- 简述主要的技术决策 -->
## 测试说明
- [ ] 单元测试已通过
- [ ] 集成测试已通过
- [ ] 手动测试了以下场景：
- 场景 1：
- 场景 2：
## AI 辅助说明
<!-- 标注哪些部分是 AI 生成的，审查者需要重点关注 -->
- AI 生成代码占比：约 ____%
- 重点审查区域：
## 审查要点
<!-- 希望审查者重点关注什么 -->Git Worktree 隔离并行任务
当你需要同时推进多个独立任务时，git worktree 是一个强大的工具，允许你在同一个仓库中同时拥有多个工作目录。
基本使用
bash
# 为并行任务创建独立工作目录
git worktree add ../project-feature-a feature/payment-integration
git worktree add ../project-feature-b feature/notification-system
# 在不同目录中用不同 AI 会话工作
# 窗口 1：cd ../project-feature-a（AI 在这里做支付集成）
# 窗口 2：cd ../project-feature-b（AI 在这里做通知系统）
# 完成后清理
git worktree remove ../project-feature-aWorktree 工作流实践
bash
# 查看所有工作目录
git worktree list
# 输出示例：
# /home/user/project abc1234 [main]
# /home/user/project-feat-a def5678 [feature/payment-integration]
# /home/user/project-feat-b ghi9012 [feature/notification-system]这种方式让多个 AI 会话可以完全独立工作，不会互相干扰文件状态。
Git 安全实践
绝对禁止的操作
bash
# ❌ 永远不要对 main/master 执行强制推送
git push --force origin main
# ❌ 永远不要在公共分支上 rebase
git rebase -i origin/main # 如果 main 是共享分支
# ❌ 不要提交包含真实密钥的文件
git add .env.production # 包含生产环境密钥
# ❌ 不要用 --amend 修改已推送的提交
git commit --amend # 如果已经推送到远端应该养成的安全习惯
bash
# ✓ 推送前总是检查即将推送的内容
git log origin/main..HEAD --oneline
# ✓ 使用 .gitignore 防止敏感文件被提交
echo ".env*" >> .gitignore
echo "*.key" >> .gitignore
# ✓ 使用 git stash 临时保存工作
git stash push -m "WIP: half-done authentication"
# ✓ 使用 git diff 审查提交前的变更
git diff --staged
# ✓ 如果不小心提交了敏感信息，立即处理
git revert HEAD # 创建新提交撤销，而不是删除历史保护分支配置
在 GitHub/GitLab 上为主要分支配置保护规则：
main 分支保护规则：
- 禁止直接推送（require PR）
- 要求至少 1 个审查者批准
- 要求 CI 检查通过
- 禁止强制推送
- 禁止删除分支处理 AI 导致的"意外变更"
AI 有时会在你没有明确要求的情况下修改额外的文件。及时发现这类变更是代码卫生的重要部分：
bash
# 提交前检查所有变更文件
git status
# 检查具体是哪些变更
git diff
# 如果发现不应该变更的文件
git checkout -- src/unrelated-file.ts # 撤销单个文件的变更
git restore src/another-file.ts # 另一种写法养成在每次提交前执行 git status 和 git diff --staged 的习惯，能有效防止意外变更进入版本历史。