25 · Git 工作流:Cursor 中的 AI 辅助版本控制
当 AI 能够帮你写代码,为什么不能让 AI 帮你管理代码的版本?
在传统开发中,Git 是我们与代码历史对话的方式。而在 Cursor 中,AI 不仅参与代码的编写,还深深融入了 Git 工作流的每一个环节——从生成提交信息、审查差异,到解决合并冲突和交互式变基。本文是 Cursor 深度系列的最后一篇核心教程,带你全面掌握 Cursor 中的 AI 辅助 Git 工作流。
01. 心智模型:AI 是你的 Git 副驾驶
在开始具体操作之前,请先建立正确的心智模型。
传统 Git 工作流:
你写代码 → 你 git add → 你 git commit → 你 git push
你解决冲突 → 你写提交信息 → 你审查 diffCursor AI 增强的 Git 工作流:
你写意图 → AI 辅助实现 → AI 生成提交信息 → 你审查 → 你 push
AI 分析冲突 → AI 提出合并方案 → 你批准
AI 分析 commit graph → AI 建议 rebase 策略 → 你确认关键区别在于:AI 承担了所有”机械性”的 Git 操作,而你把控最终的安全闸门。 你不是在放弃控制权,而是在把 Git 从”工具”升级为”协作者”。
02. AI 辅助提交:从 git add 到智能暂存
2.1 Composed Commits(组合提交)
Cursor 的 Composed Commits 功能允许你通过自然语言描述来构建一个完整的提交。
实际操作步骤:
- 打开 Source Control 面板(
Ctrl+Shift+G/Cmd+Shift+G) - 点击 Changes 区域右上角的 ”+” 图标旁边的 AI 按钮
- 在弹出的输入框中描述你要提交的内容,例如:
"完成了用户认证模块的 JWT 实现,包括 token 生成、验证和中间件集成。
同时修复了登录页面在移动端显示的布局问题。"- AI 会自动分析你的变更,将文件分组到逻辑单元中
- 你可以审查 AI 的分组,确认无误后直接提交
2.2 智能暂存(Smart Staging)
AI 可以帮你决定哪些文件应该放在一起提交。它通过分析变更内容的关联性来做出判断:
| 场景 | AI 的行为 |
|---|---|
| 多个文件修改了同一个功能 | 自动分组到同一个提交 |
| 混合了功能开发和格式修复 | 建议拆分为不同提交 |
| 配置文件和环境变量变更 | 单独标记,提醒你注意 |
实用技巧: 在 AI 输入框中使用 / 命令可以快速指定提交策略:
/group— 让 AI 自动分组变更/commit "信息"— 直接生成提交/stash— 将当前变更暂存
03. Diff Review:在 Agent Review Tab 中审查变更
3.1 什么是 Agent Review Tab
Agent Review Tab 是 Cursor 中专门用于审查代码变更的面板。当你让 AI Agent 执行一个任务后,所有变更都会汇总到这个标签页中,等待你逐行审查。
界面组成:
┌──────────────────────────────────────┐
│ Agent Review │ Accept All │ ✕ │
├──────────────────────────────────────┤
│ 📁 src/auth/jwt.ts (+45 -12) │
│ 📁 src/auth/middleware.ts (+23 -3) │
│ 📁 src/pages/login.tsx (+8 -15) │
├──────────────────────────────────────┤
│ ┌─ diff ──────────────────────────┐ │
│ │ - const secret = "hardcoded"; │ │
│ │ + const secret = process.env. │ │
│ │ JWT_SECRET; │ │
│ └─────────────────────────────────┘ │
│ ┌─── AI 解释 ─────────────────────┐ │
│ │ 将硬编码的密钥改为环境变量读取, │ │
│ │ 提高安全性。 │ │
│ └─────────────────────────────────┘ │
└──────────────────────────────────────┘3.2 审查策略
作为开发者,你在 Agent Review Tab 中应该关注什么?
- 业务逻辑是否正确 — AI 理解对了你的需求吗?
- 安全性 — 有没有暴露密钥、没有做输入校验?
- 边界情况 — AI 考虑了空值、越界、异常吗?
- 代码风格 — 虽然 AI 通常很好,但项目规范优先
审查快捷键:
| 操作 | 快捷键 |
|---|---|
| 接受当前文件 | Cmd+Shift+Y |
| 拒绝当前文件 | Cmd+Shift+N |
| 逐块导航 | Alt+↑/↓ |
| 全量接受 | 点击 “Accept All” |
| 在编辑器中打开 diff | 双击文件列表 |
黄金审查原则: 永远不要因为”AI 写的所以肯定没问题”而跳过审查。每一行变更都需要你理解——这是你的代码库,AI 只是工具。
04. 生成提交信息:从自然语言到规范格式
4.1 AI 如何生成提交信息
Cursor 的 AI 会分析你的变更内容,自动生成符合 Conventional Commits 规范的提交信息。
分析维度:
- 变更的文件 — 涉及哪些模块?
- 变更的类型 — 新增功能?修复 bug?重构?文档?
- 变更的范围 — 影响面有多大?
- 破坏性变更 — API 是否不兼容?
生成的提交信息示例:
feat(auth): 实现 JWT token 生成与验证机制
- 添加 token 生成函数,支持自定义过期时间
- 实现 token 验证中间件,集成到路由保护
- 修复移动端登录页面布局偏移问题
- 将硬编码密钥迁移至环境变量
Closes #1424.2 自定义提交格式
你可以在 Cursor 设置中自定义提交信息的模板:
// settings.json
{
"git.commitMessageTemplate": {
"format": "conventional",
"scope": "auto",
"includeFooter": true,
"maxLength": 72,
"language": "chinese"
}
}常用模板模式:
conventional— 标准 Conventional Commits(推荐)gitmoji— 😊 开头带 emojisimple— 简短的一句话custom— 完全自定义模板
4.3 手动润色
AI 生成的信息通常质量很高,但你可以直接编辑它。点击提交信息输入框,AI 的建议会以补全形式出现,按 Tab 接受,继续输入则手动编辑。
05. 处理合并冲突:AI 成为调解员
5.1 传统冲突解决 vs AI 辅助
合并冲突是 Git 使用中最令人头疼的问题。Cursor 将 AI 引入冲突解决流程,让这个过程从”痛苦”变为”可管理”。
| 维度 | 传统方式 | Cursor AI 辅助 |
|---|---|---|
| 理解冲突 | 你需要阅读双方代码才能理解 | AI 自动分析冲突双方的意图 |
| 解决方案 | 你手动编辑冲突标记 | AI 提出 2-3 种合并方案 |
| 正确性验证 | 你凭经验判断 | AI 交叉检查语法和类型 |
| 大文件冲突 | 极其痛苦 | AI 能处理数千行的冲突文件 |
5.2 实际操作
当遇到合并冲突时,Cursor 会在冲突文件中显示一个特殊的 AI 按钮:
<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 3000;
const retryCount = 3;
>>>>>>> feature/retry-logic点击冲突标记上方的 “Resolve with AI” 按钮,AI 会分析并给出建议:
AI 分析结果:
- HEAD (当前分支): 超时时间 5000ms,无重试
- feature/retry-logic: 超时时间 3000ms,增加重试机制
建议方案:
方案 A: 保留 HEAD 的超时 + feature 的重试
const timeout = 5000;
const retryCount = 3;
方案 B: 使用 feature 的完整逻辑
const timeout = 3000;
const retryCount = 3;
方案 C: 取折中值,增加配置化
const timeout = 4000;
const retryCount = 2;你只需选择一个方案,AI 会帮你清理冲突标记并应用代码。
5.3 冲突预防
Cursor AI 还可以在你执行 git merge 或 git rebase 之前,预分析可能出现的冲突,并给出预防建议。在终端中运行合并命令前,可以问 AI:
“合并 feature/login 到当前分支,可能会有什么冲突?”
AI 会扫描两个分支的差异,找出重叠的修改区域,并提前给出风险预警。
06. 交互式变基(Interactive Rebase)辅助
6.1 AI 辅助的变基策略
交互式变基(git rebase -i)是整理提交历史的利器,但也是最容易出错的 Git 操作之一。Cursor AI 可以帮你:
- 分析提交历史 — 理解每个提交的上下文
- 建议合并策略 — 哪些提交应该 squash(压缩)
- 自动排序 — 按逻辑重新排列提交顺序
- 处理冲突 — 在变基过程中遇到冲突时自动解决
6.2 在 Cursor 中执行 rebase
方式一:通过 Chat/Option+K 询问
你: "帮我 rebase 最近 5 个提交,把 fix typo 和 fix formatting 合并到前一个提交中"
AI: "好的,我将执行以下操作:
1. pick a1b2c3d feat: 添加用户注册功能
2. squash e4f5g6h fix: 修复 typo → 合并到 a1b2c3d
3. squash i7j8k9l fix: 格式化代码 → 合并到 a1b2c3d
4. pick m0n1o2p feat: 添加邮箱验证
请确认是否继续?"方式二:通过 Source Control 面板
在 Source Control 面板中,展开提交历史,右键点击提交节点,选择 “AI Squash…” 或 “AI Reorder…”,AI 会引导你完成操作。
6.3 安全回滚
AI 在执行变基前会自动创建一个备份分支:
git branch backup/rebase-2025-07-03如果变基结果不满意,你可以随时切回备份分支。这个备份在变基完成后会被 AI 删除(需要你确认)。
07. .cursorignore:Git 感知的智能索引控制
7.1 什么是 .cursorignore
.cursorignore 是 Cursor 的配置文件,用于控制哪些文件应该被 AI 索引(纳入上下文理解),类似于 .gitignore 控制哪些文件被 Git 跟踪。
关键区别:
| 特性 | .gitignore | .cursorignore |
|---|---|---|
| 控制目标 | Git 版本控制 | Cursor AI 索引 |
| 默认排除 | 编译产物、依赖 | 同 .gitignore + 更多 |
| 影响 | git add/status | AI 代码补全、Agent 上下文 |
| 是否必须 | 是 | 推荐,大型项目必备 |
7.2 为什么需要 .cursorignore
当你在包含大量文件的项目(如 monorepo、node_modules、生成目录)中使用 Cursor 时,AI 的索引会变得缓慢且不精确。通过 .cursorignore,你可以:
- 减少索引噪音 — AI 不会把无关文件纳入理解
- 加速 AI 响应 — 索引量减少,检索速度提升
- 提高补全质量 — AI 只关注真正相关的代码
推荐的 .cursorignore 配置:
# 依赖目录
node_modules/
.pnpm-store/
vendor/
# 构建产物
dist/
build/
.out/
.next/
# 生成文件
*.generated.*
generated/
protobuf/
# 日志和缓存
*.log
.cache/
.eslintcache
# 大型数据文件
*.csv
*.parquet
data/
# 测试报告
coverage/
test-results/
# Git 相关(无需 AI 索引)
.git/
.git-blame-ignore-revs7.3 最佳实践
- 从 .gitignore 复制 —
.cursorignore的起点可以是你已有的.gitignore - 更严格 — 还可以排除 AI 不关心的测试 fixture、mock 数据、文档快照
- 分层配置 — 支持子目录级别的
.cursorignore,在 monorepo 中非常有用 - 排除不删除 — 和
.gitignore一样,它只控制索引,不删除文件
08. 黄金法则:AI 可以提交本地,你手动推送
8.1 安全边界
这是 Cursor Git 工作流中最重要的原则,我称之为 “黄金法则”:
AI 可以执行任何本地 Git 操作——暂存、提交、分支、合并、变基——但永远不会自动执行
git push到远程仓库。
为什么?
本地操作(AI 可执行) 远程操作(仅人类)
───────────────────── ─────────────────
git add ← 暂存变更 git push ← 推送代码
git commit ← 记录提交 git push --force ← 强制推送
git stash ← 暂存工作区 git tag --push ← 发布标签
git branch ← 管理分支 git push --delete ← 删除远程分支
git merge ← 合并分支
git rebase ← 整理历史本地操作可以被审查、被撤销、被修改。推送是一个不可逆的公开动作——一旦代码推送到远程,它就被发布出去了。AI 没有权限做这个决定。
8.2 实际操作流程
你 → AI Agent: "实现用户登录功能"
AI: 生成代码,展示在 Agent Review Tab
你: 审查变更,逐行确认
你: 点击 "Accept All"
AI: 自动创建提交 (git commit)
你: 运行测试,确认无误
你: 手动 git push (或点击 Source Control 的推送按钮)8.3 例外情况
在极少数情况下,你可以通过 Cursor 的 Rules 配置允许 AI 执行推送:
// .cursor/rules/push-allow.json
{
"name": "允许 AI 推送",
"description": "仅在特定分支允许 AI 推送",
"git": {
"allowPush": true,
"allowedBranches": ["dev/*", "feature/*"]
}
}但请慎重使用。 默认保持黄金法则是一个不会后悔的选择。
09. Checkpoint vs Git 提交:两种保存机制
9.1 Checkpoint 是什么
Checkpoint 是 Cursor 的自动保存点,它在你使用 AI Agent 的过程中自动创建。每次 AI 应用一批变更后,Cursor 都会创建一个 Checkpoint。
| 特性 | Checkpoint | Git 提交 |
|---|---|---|
| 创建者 | Cursor 自动创建 | 开发者主动创建 |
| 保存内容 | 工作区完整快照 | 暂存区的变更集 |
| 可见性 | 仅在 Cursor 中 | 在所有 Git 工具中可见 |
| 可分享 | 否,仅本地 | 是,推送到远程 |
| 生命周期 | 临时(可配置保留策略) | 永久(除非显式删除) |
| 回滚 | 完全恢复工作区 | 恢复到某个提交状态 |
| 关联上下文 | 包含 AI 对话上下文 | 仅有提交信息 |
9.2 Checkpoint 的使用场景
场景一:实验性变更
你在尝试一个重构方案,不确定是否可行。AI Agent 执行了变更,但你想先看看效果再决定是否保留。
场景二:逐步审查
AI Agent 执行了多个文件的大范围修改。每个步骤都有 Checkpoint,你可以逐个查看变更的演化过程。
9.3 最佳实践:结合使用
开发流程:
1. AI 开始任务前 → 自动创建 Checkpoint A
2. AI 完成第一批变更 → 自动创建 Checkpoint B
3. 你审查 → 接受部分变更
4. AI 继续 → 自动创建 Checkpoint C
5. 全部完成 → 你审查 → AI 创建 Git 提交
6. Checkpoint 在提交后标记为"可清理"推荐工作流:
- 开发阶段:依赖 Checkpoint 快速迭代和回滚
- 完成阶段:创建规范的 Git 提交,推送到远程
- 保留策略:Checkpoint 保留最近 7 天或最近 50 个
10. 实用场景示例
10.1 日常开发流程
场景:修复登录页面的表单验证 bug
1. 你: "修复登录表单的邮箱验证,目前不校验@符号"
2. AI Agent 分析代码,修改验证函数,更新测试
3. Agent Review Tab 显示:
- 📁 src/utils/validation.ts (+5 -2)
- 📁 src/tests/validation.test.ts (+10 -0)
4. AI 解释变更:
"在 validateEmail() 中添加了 @ 符号检查,
同时确保域名部分至少有一个点号。"
5. 你审查 → 确认无误 → Accept
6. AI 自动创建提交:
"fix(login): 修复邮箱验证未检查 @ 符号的问题"
7. 你本地运行测试 → 通过
8. 你手动 git push10.2 合并冲突解决
场景:合并 feature/notification 分支时产生冲突
1. 执行 git merge feature/notification
2. Cursor 检测到冲突文件: src/services/notify.ts
3. 点击 "Resolve with AI"
4. AI 分析:
"冲突主要在两个函数:
- HEAD: sendNotification() 使用 WebSocket
- feature: sendNotification() 使用 Server-Sent Events (SSE)
AI 建议: 保留 SSE 方案,因为它更适合当前的架构"
5. 你选择 "应用方案"
6. AI 自动解决冲突,清理标记
7. 你确认合并结果 → 提交合并10.3 提交历史整理
场景:发布前整理 feature 分支的提交历史
1. 你: "帮我整理 feature/checkout 分支的提交历史"
2. AI 分析 12 个提交:
- 6 个有意义的提交(新功能、重构)
- 4 个 fixup 和 typo 修正(应 squash)
- 2 个 "WIP" / "debug" 提交(应 squash 或删除)
3. AI 提出计划:
pick feat: 添加购物车功能
squash fix: 购物车数量计算错误 → 合并到上一个
squash fix: 变量命名错误 → 合并到上一个
pick refactor: 抽离价格计算逻辑
drop debug: 临时调试代码 → 删除
4. 你确认 → AI 执行 rebase
5. 最终 8 个干净提交,可以推送11. 设置与配置参考
11.1 推荐的 Git 设置
// settings.json
{
"git.enableSmartCommit": true,
"git.commitMessageTemplate": {
"format": "conventional",
"language": "auto"
},
"git.autoCommitAfterAgent": true,
"git.autoFetch": true,
"git.enableAbortOnConflict": false,
"git.checkpoint": {
"enabled": true,
"maxCount": 50,
"retentionDays": 7
},
"git.rebase": {
"createBackup": true,
"autoSquashFixup": true
}
}11.2 快捷键速查
| 功能 | Mac | Windows/Linux |
|---|---|---|
| 打开 Source Control | Cmd+Shift+G | Ctrl+Shift+G |
| Agent Review Tab | Cmd+Shift+A | Ctrl+Shift+A |
| 接受当前文件变更 | Cmd+Shift+Y | Ctrl+Shift+Y |
| 拒绝当前文件变更 | Cmd+Shift+N | Ctrl+Shift+N |
| AI 生成提交信息 | 在提交输入框按 Cmd+K | Ctrl+K |
| 解决冲突 | 点击 “Resolve with AI” | 同上 |
| 创建 Checkpoint | 自动(或手动 Cmd+Shift+C) | Ctrl+Shift+C |
12. 总结
Cursor 的 Git 工作流将 AI 深度融入到版本控制的每一个环节。回顾核心要点:
| 能力 | 核心价值 | 你的职责 |
|---|---|---|
| AI 辅助提交 | 智能分组、自动提交 | 审查变更内容 |
| Diff Review | 逐行审查 AI 变更 | 确认正确性和安全性 |
| 提交信息生成 | 符合规范的自动文案 | 润色和补充上下文 |
| 冲突解决 | AI 分析并提供方案 | 选择最佳方案 |
| Rebase 辅助 | 自动分析并执行 | 确认最终结果 |
| .cursorignore | 控制 AI 索引范围 | 合理配置 |
| 黄金法则 | 本地操作 + 手动推送 | 执行推送 |
| Checkpoint | 自动快照保护 | 利用它大胆实验 |
黄金法则永远在: AI 可以提交本地,你手动推送。这不仅仅是安全策略——它体现了 AI 作为协作者而非替代者的角色定位。你始终拥有最终决定权。
下一篇
从单个文件到整个代码库:在 Cursor 中使用 AI 进行跨文件编辑和代码重构的高级技巧。
本文是 Cursor 深度教程系列的第 25 篇。本系列从入门到进阶,全面覆盖 Cursor AI 编辑器的使用技巧和最佳实践。