第五章. Vibe KanBan 代码审查、PR 集成与分支管理
第五章. Vibe KanBan 代码审查、PR 集成与分支管理
Prorise第五章. Vibe KanBan 代码审查、PR 集成与分支管理
本章将带你完成从任务执行到代码合并的完整流程,包括代码审查、GitHub PR 创建、冲突解决和分支管理策略。
5.1. 创建示例项目并推送到 GitHub
在学习代码审查和 PR 集成之前,我们需要先准备一个真实的 GitHub 仓库。这样才能体验完整的协作流程。
5.1.1. 创建本地项目
我们将创建一个简单的 Todo 应用作为示例项目。
步骤 1:初始化项目
打开 PowerShell,执行以下命令:
1 | # 创建项目目录 |
步骤 2:初始化 Git 仓库
1 | # 初始化 Git |
5.1.2. 在 GitHub 上创建远程仓库
步骤 1:登录 GitHub
访问 github.com 并登录你的账号。
步骤 2:创建新仓库
- 点击右上角的 “+” 按钮,选择 “New repository”
- 填写仓库信息:
| 字段 | 填写内容 |
|---|---|
| Repository name | vibe-todo-demo |
| Description | A demo project for Vibe Kanban tutorial |
| Visibility | Public(公开)或 Private(私有) |
| Initialize this repository | ❌ 不要勾选任何选项 |
- 点击 “Create repository”
步骤 3:推送本地代码到 GitHub
GitHub 会显示一个快速设置页面,复制 “push an existing repository” 部分的命令:
1 | # 添加远程仓库(替换为你的 GitHub 用户名) |
步骤 4:验证推送成功
刷新 GitHub 仓库页面,你应该能看到刚才提交的代码。
5.1.3. 在 Vibe Kanban 中导入项目
步骤 1:启动 Vibe Kanban
1 | npx vibe-kanban |
步骤 2:创建项目
- 点击 “Create Project”
- 选择 “From existing git repository”
- 选择
vibe-todo-demo目录 - 配置项目信息:
| 配置项 | 值 |
|---|---|
| Project Name | Todo Demo |
| Base Branch | main |
- 点击 “Create”
步骤 3:配置项目脚本
进入项目设置页面,配置以下脚本:
Setup Scripts:
1 | pnpm install |
Dev Server Scripts:
1 | pnpm run dev |
Copy Files:
1 | .env, .env.local |
点击 “Save” 保存配置。
5.2. 代码审查流程:从 Diff 到合并决策
现在我们有了一个完整的 GitHub 项目,可以开始学习代码审查流程了。
5.2.1. 创建第一个任务
步骤 1:创建任务
在 Vibe Kanban 看板中,点击 “+” 创建新任务:
| 字段 | 内容 |
|---|---|
| Title | 实现 Todo 输入组件 |
| Description | 见下方 |
| Base Branch | main |
| Agent | GEMINI_FLASH |
任务描述:
1 | ## 任务目标 |
步骤 2:启动任务
点击 “Create & Start”,Vibe Kanban 会:
- 创建分支
feature/todo-input - 创建 Worktree
- 启动 Gemini Agent
等待 Agent 完成任务(通常需要 1-3 分钟)。
5.2.2. 查看代码变更(Diff)
当 Agent 完成任务后,任务状态会变为 “Review”。
步骤 1:打开任务详情
点击任务卡片,进入任务详情页面。
步骤 2:查看文件变更列表
在任务详情页面,你会看到 “Changes” 标签页,显示所有被修改的文件:
| 文件路径 | 变更类型 | 行数变化 |
|---|---|---|
src/components/TodoInput.tsx | 新增 | +45 |
src/App.tsx | 修改 | +3, -1 |
步骤 3:查看具体代码变更
点击文件名,会展开 Diff 视图:
Diff 视图的关键元素:
| 符号 | 含义 |
|---|---|
+ 绿色行 | 新增的代码 |
- 红色行 | 删除的代码 |
| 灰色行 | 未修改的上下文代码 |
5.2.3. 添加行级评论
如果你发现代码有问题,可以直接在 Diff 视图中添加评论。
步骤 1:点击代码行号
将鼠标悬停在代码行号上,会出现一个 “+” 按钮。
步骤 2:添加评论
点击 “+” 按钮,输入评论内容:
1 | 这里应该使用 `onKeyDown` 而不是 `onKeyPress`,因为 `onKeyPress` 已经被废弃了。 |
步骤 3:提交评论
点击 “Add Comment” 按钮,评论会被保存。
批量添加评论:
你可以在多个代码行上添加评论,然后点击页面底部的 “Submit Review” 按钮,一次性发送所有评论给 Agent。
5.2.4. 审查决策:通过或不通过
在查看完所有代码变更后,你需要做出审查决策。
决策 1:审查通过
如果代码质量满足要求,点击 “Approve” 按钮。
Vibe Kanban 会:
- 将任务状态变更为 “Approved”
- 准备合并代码到主分支
- 你可以选择合并策略(见 5.4 节)
决策 2:审查不通过(Request Changes)
如果代码存在问题,点击 “Request Changes” 按钮。
Vibe Kanban 会:
- 将所有评论发送给 Agent
- Agent 会根据评论修改代码
- 修改完成后,任务状态重新变为 “Review”
- 你需要再次审查
决策 3:手动修改代码
如果你想自己修改代码,点击 “Open in Editor” 按钮。
Vibe Kanban 会:
- 在 VS Code/Cursor 中打开 Worktree 目录
- 你可以手动修改代码
- 修改完成后,回到 Vibe Kanban 点击 “Refresh Changes”
5.2.5. 使用 Follow-up 消息引导 Agent
如果你不想添加行级评论,也可以直接在聊天框中发送 Follow-up 消息。
步骤 1:打开聊天面板
在任务详情页面,点击 “Chat” 标签页。
步骤 2:发送 Follow-up 消息
在聊天框中输入:
1 | 代码整体不错,但有两个问题需要修改: |
步骤 3:等待 Agent 修改
Agent 会根据你的反馈修改代码,修改完成后任务状态重新变为 “Review”。
5.3. GitHub PR 集成:从任务到 Pull Request
Vibe Kanban 提供了与 GitHub 的深度集成,可以直接从任务创建 Pull Request。
5.3.1. 配置 GitHub 集成
步骤 1:打开设置页面
在 Vibe Kanban 中,点击右上角的 设置图标(⚙️)。
步骤 2:配置 GitHub Token
- 点击左侧菜单的 “Integrations”
- 找到 “GitHub Integration” 部分
- 点击 “Connect GitHub”
步骤 3:生成 GitHub Personal Access Token
Vibe Kanban 会引导你创建 GitHub Token:
- 访问 github.com/settings/tokens
- 点击 “Generate new token (classic)”
- 配置 Token 权限:
| 权限 | 说明 |
|---|---|
| repo | 完整的仓库访问权限(必选) |
| workflow | 更新 GitHub Actions 工作流(可选) |
- 点击 “Generate token”
- 复制生成的 Token(格式:
ghp_xxxxxxxxxxxx)
步骤 4:在 Vibe Kanban 中保存 Token
将 Token 粘贴到 Vibe Kanban 的输入框中,点击 “Save”。
5.3.2. 从任务创建 Pull Request
步骤 1:审查通过任务
确保任务已经通过代码审查(状态为 “Approved”)。
步骤 2:点击 “Create PR” 按钮
在任务详情页面,点击右上角的 “Create PR” 按钮。
步骤 3:确认 PR 信息
Vibe Kanban 会自动填充 PR 信息:
| 字段 | 自动填充内容 |
|---|---|
| Title | 任务标题(如 “实现 Todo 输入组件”) |
| Description | 任务描述 + 代码变更摘要 |
| Base Branch | main |
| Head Branch | feature/todo-input |
你可以修改这些信息,然后点击 “Create”。
步骤 4:查看 PR 状态
PR 创建成功后,Vibe Kanban 会:
- 在任务卡片上显示 PR 链接
- 自动同步 PR 状态(Open / Merged / Closed)
- 如果 PR 被合并,任务状态自动变为 “Done”
5.3.3. PR 状态自动同步
Vibe Kanban 会定期检查 GitHub PR 的状态,并自动更新任务状态。
| GitHub PR 状态 | Vibe Kanban 任务状态 |
|---|---|
| Open | Review |
| Merged | Done |
| Closed (未合并) | Cancelled |
手动刷新 PR 状态:
如果你在 GitHub 上合并了 PR,但 Vibe Kanban 还没有同步,可以点击任务详情页面的 “Refresh PR Status” 按钮。
5.3.4. 使用 Push 按钮更新 PR
如果你在代码审查后又修改了代码,需要更新 PR。
步骤 1:修改代码
在 Vibe Kanban 中,通过 Follow-up 消息或手动修改代码。
步骤 2:点击 “Push” 按钮
在任务详情页面,点击 “Push to PR” 按钮。
Vibe Kanban 会:
- 将新的提交推送到 GitHub
- 更新 PR 的代码变更
- 在 PR 中添加评论:“Updated by Vibe Kanban”
5.4. 任务完成与合并策略
当代码审查通过后,你需要选择合适的合并策略将代码合并到主分支。
5.4.1. 三种合并策略对比
Vibe Kanban 支持三种 Git 合并策略:
| 策略 | Git 命令 | 提交历史 | 适用场景 |
|---|---|---|---|
| Merge | git merge --no-ff | 保留所有提交 + 合并提交 | 需要完整历史记录的项目 |
| Squash | git merge --squash | 合并为单个提交 | 希望保持主分支简洁 |
| Rebase | git rebase | 线性历史,无合并提交 | 追求干净的提交历史 |
Merge 策略示意图:
1 | main: A---B---C-------G |
合并后 main 分支包含:A, B, C, D, E, F, G(G 是合并提交)
Squash 策略示意图:
1 | main: A---B---C---D' |
合并后 main 分支包含:A, B, C, D’(D’ 是 D+E+F 的合并)
Rebase 策略示意图:
1 | main: A---B---C---D---E---F |
合并后 main 分支包含:A, B, C, D, E, F(线性历史)
5.4.2. 选择合适的合并策略
使用 Merge 的场景:
| 场景 | 原因 |
|---|---|
| 开源项目 | 需要保留贡献者的完整提交历史 |
| 大型团队 | 需要追溯每个提交的来源 |
| 长期维护的项目 | 需要完整的历史记录用于回溯 |
使用 Squash 的场景:
| 场景 | 原因 |
|---|---|
| 功能分支 | 将多个 WIP 提交合并为一个有意义的提交 |
| 小型团队 | 保持主分支简洁,易于阅读 |
| 快速迭代项目 | 不需要保留每个细节提交 |
使用 Rebase 的场景:
| 场景 | 原因 |
|---|---|
| 个人项目 | 追求最干净的提交历史 |
| 严格的提交规范 | 每个提交都经过精心设计 |
| 需要 Bisect 的项目 | 线性历史便于使用 git bisect 定位问题 |
5.4.3. 在 Vibe Kanban 中执行合并
步骤 1:选择合并策略
在任务详情页面,点击 “Complete Task” 按钮。
Vibe Kanban 会弹出合并策略选择对话框:
1 | ┌─────────────────────────────────────┐ |
步骤 2:编辑提交信息
如果选择 Squash 策略,你需要编辑合并后的提交信息。
推荐的提交信息格式(遵循 Conventional Commits):
1 | <type>(<scope>): <subject> |
示例:
1 | feat(components): 实现 Todo 输入组件 |
步骤 3:执行合并
点击 “Merge” 按钮,Vibe Kanban 会:
- 执行选定的合并策略
- 将代码合并到
main分支 - 推送到 GitHub(如果配置了远程仓库)
- 删除任务分支和 Worktree
- 将任务状态变更为 “Done”
5.5. 冲突解决:处理 Rebase 冲突
在多人协作或长时间开发的任务中,你的任务分支可能会落后于主分支,导致合并时出现冲突。
5.5.1. 什么时候会出现冲突
场景 1:主分支有新提交
1 | main: A---B---C---D (你的队友提交了 D) |
当你尝试合并 feature 到 main 时,如果 D 和 E 修改了同一个文件的同一行,就会产生冲突。
场景 2:多个任务修改同一文件
假设你有两个任务:
- 任务 1:修改
App.tsx的第 10 行 - 任务 2:也修改
App.tsx的第 10 行
如果任务 1 先合并,任务 2 在合并时就会产生冲突。
5.5.2. Vibe Kanban 的冲突检测
当你点击 “Complete Task” 时,Vibe Kanban 会自动检测是否存在冲突。
如果存在冲突,会显示以下提示:
1 | ┌─────────────────────────────────────┐ |
5.5.3. 自动解决冲突(让 Agent 处理)
步骤 1:点击 “Resolve Automatically”
Vibe Kanban 会启动 Agent,让它分析冲突并生成解决方案。
步骤 2:Agent 分析冲突
Agent 会读取冲突文件,理解双方的修改意图,然后生成合并后的代码。
冲突文件示例:
1 | // src/App.tsx |
Agent 的解决方案:
Agent 会分析:
main分支使用todos和Todo[]类型- 你的分支使用
tasks和Task[]类型
Agent 会选择保留 main 分支的命名(因为它是最新的),并更新你的代码以匹配。
步骤 3:审查 Agent 的解决方案
Agent 完成后,你需要审查它的解决方案:
1 | // Agent 生成的合并结果 |
如果满意,点击 “Accept” 继续合并。
5.5.4. 手动解决冲突(使用编辑器)
如果你不信任 Agent 的自动解决方案,可以选择手动解决。
步骤 1:点击 “Resolve Manually”
Vibe Kanban 会在 VS Code/Cursor 中打开 Worktree 目录。
步骤 2:查找冲突文件
在编辑器中,冲突文件会被标记为红色。打开 src/App.tsx:
1 | function App() { |
步骤 3:编辑冲突区域
删除冲突标记(<<<<<<<, =======, >>>>>>>),保留你想要的代码:
1 | function App() { |
步骤 4:标记冲突已解决
在终端中执行:
1 | # 标记文件已解决 |
步骤 5:回到 Vibe Kanban
回到 Vibe Kanban,点击 “Refresh” 按钮,确认冲突已解决。
5.5.5. 放弃合并(Abort)
如果冲突太复杂,或者你想重新规划任务,可以选择放弃合并。
步骤 1:点击 “Abort Merge”
Vibe Kanban 会执行




