AI Skills
create-pr

create-pr

热门

为当前分支在 warp 仓库中创建拉取请求。当用户提到打开 PR、创建拉取请求、提交更改以供审查或准备合并代码时使用。

124Star
0Fork
更新于 2026/7/10
获取 Skill源代码

相关 Skills

frontend-testing15万next-cache-components-optimizer14万vitest11万
SKILL.md
readonly只读
name
create-pr
description

为当前分支在 warp 仓库中创建拉取请求。当用户提到打开 PR、创建拉取请求、提交更改以供审查或准备合并代码时使用。

create-pr

概述

本指南涵盖了在 warp 仓库中创建拉取请求的最佳实践，包括合并 master、运行预提交检查、关联 Linear 任务、确保适当的测试覆盖率以及构建有效的 PR 以进行审查。

相关技能

  • fix-errors - 在打开 PR 前修复预提交失败（格式化、lint、测试）
  • warp-integration-test - 为用户可见流程、回归和 P0 用例添加或更新集成测试覆盖
  • add-feature-flag - 将更改置于功能标志之后

PR 前检查清单

1. 将 master 合并到你的功能分支

在开始审查流程之前，始终将 master 合并到你的功能分支。

git fetch origin
git merge origin/master

在打开 PR 之前，在本地解决所有合并冲突。

2. 对代码更改运行预提交检查

如果 PR 包含代码更改，请在打开或更新 PR 之前运行相关的预提交检查：

./script/presubmit

./script/presubmit 运行：

  • cargo fmt - 代码格式化
  • cargo clippy - 将所有警告视为错误的 lint
  • 所有测试（单元测试、文档测试和集成测试）
    如果 PR 仅涉及文档（例如技能、markdown 或其他非代码内容），则无需仅为了打开或更新 PR 而运行 cargo fmt 或 cargo clippy。

如果预提交检查对包含代码更改的 PR 失败，请使用 fix-errors 技能解决问题。

在以下情况下，你必须运行 cargo fmt 和 cargo clippy：

  • 打开包含代码更改的新 PR
  • 向包含代码更改的现有 PR 分支推送新提交
  • 任何更改代码的已审查分支更新

3. 审查你的更改

在创建 PR 之前，审查你即将提交的更改：

# 查看分支中的提交（与基础分支比较）
git --no-pager log <base-branch>..HEAD --oneline

# 查看更改的文件统计信息
git --no-pager diff <base-branch>...HEAD --stat

# 查看完整差异
git --no-pager diff <base-branch>...HEAD

这有助于你：

  • 验证所有预期更改都已包含
  • 在审查前发现意外更改
  • 编写准确的 PR 描述
  • 确保你正在与正确的基础分支进行比较
  • 测试： 在需要时包含测试——错误修复（回归测试）、算法代码（单元测试）、UI 组件（布局测试）、P0 用例（集成测试）。请参阅下面的测试要求。

4. 关联到 Linear 任务

如果可能，PR 应与 Linear 任务关联。使用 Linear MCP 工具（如果可用）查找对应的问题。

分支命名约定：
远程分支应以你的名字为前缀（例如 zheng/feature、alice/fix-bug）。

如何将 PR 关联到 Linear：
在 PR 标题中包含问题 ID（例如 [WARP-1234] Add new feature）。在创建 PR 之前执行此操作以实现自动关联。

5. 打开 PR

打开 PR 时使用位于 .github/pull_request_template.md 的 PR 模板。

在适当时使用 PR 模板底部的格式添加变更日志条目。一些示例：

  • 功能：“在当前目录中跨文件进行全局搜索。使用 CMD-F/CTRL-SHIFT-F 打开。”
  • 改进：“在跳转到行/列时添加了水平自动滚动。”
  • 错误修复：“修复了代理运行命令时会话查看器输入被清除的问题。”

CLI 工作流程：

  • 检查当前分支是否存在 PR：

    gh pr view --json number,url

    退出码 0 表示存在 PR，1 表示不存在。

  • 创建新 PR：

    # 带有标题和正文
gh pr create --title "Title" --body "Description" --draft

# 从提交自动填充
gh pr create --fill --draft

# 使用 PR 模板文件
gh pr create --body-file .github/pull_request_template.md --title "Title" --draft

    关键标志：--draft / -d、--fill / -f、--body-file / -F、--web / -w

  • 更新现有 PR：

    gh pr edit --title "New title" --body "New body"
gh pr edit --add-reviewer username --add-label bug

  • 将 PR 标记为准备审查：

    gh pr ready

6. 包含共同作者归属

在提交更改或创建 PR 时，在每个提交消息或 PR 描述的末尾包含归属：

Co-Authored-By: Warp <agent@warp.dev>

测试要求

错误修复需要回归测试

所有错误修复都应附带回归测试。 这有助于防止之前已损坏的内容再次被破坏。

测试应：

  • 重现原始错误（在修复前会失败）
  • 在应用修复后通过
  • 明确命名以指示它正在防止什么错误

算法代码需要单元测试

具有非平凡逻辑的代码应有单元测试以验证功能：

需要单元测试的示例：

  • 自定义数据结构（例如 SumTree）
  • 应针对给定查询返回预期结果的搜索相关 API
  • UI 框架中的核心布局代码
  • 任何算法或计算逻辑

不需要的情况：

  • 足够简单的函数
  • 平凡的 getter/setter

遵循仓库的本地测试约定以获取编写单元测试的指导。

UI 组件需要布局验证测试

所有 UI 组件（View 的实现）都应有一个简单的单元测试，以验证它们可以在不 panic 的情况下进行布局。

这提供了对渲染“安全性”（而非“正确性”）的高级覆盖：

#[test]
fn test_component_can_layout() {
    use warpui::App;
    use warp::test_util::{terminal::initialize_app_for_terminal_view, add_window_with_terminal};
    
    App::test((), |mut app| async move {
        initialize_app_for_terminal_view(&mut app);
        let term = add_window_with_terminal(&mut app, None);
        
        // 渲染组件 - 不应 panic
        term.update(&mut app, |view, ctx| {
            // 创建并布局你的组件
        });
    })
}

在跳过集成测试覆盖前询问用户

如果 PR 更改了用户可见的流程、修复了端到端回归，或者看起来会受益于集成测试覆盖，请在创建或更新 PR 之前使用 ask_user_question 工具询问用户是否希望将集成测试作为工作的一部分添加。

优先选择直接的选择，例如：

  • Yes, add an integration test before creating the PR
  • No, continue without an integration test

如果用户选择添加，请使用 warp-integration-test 技能。

P0 用例需要集成测试

所有“P0 用例”都需要一个集成测试，以覆盖相关行为/流程。

“P0 用例”定义为： 应用程序的任何行为，如果被破坏，则需要带外发布。

集成测试应：

  • 执行完整的面向用户流程
  • 验证端到端功能
  • 放置在 integration/ 目录中

使用 warp-integration-test 技能获取实现细节、测试注册步骤和验证工作流程。

PR 描述指南

你的 PR 摘要（在“Description”部分下）应包括：

  1. 什么 - 正在进行的更改是什么
  2. 为什么 - 为什么需要这些更改（如果适用，链接到 Linear 任务）
  3. 如何 - 所采取方法的简要说明

打开 PR 后

  1. 监控 CI 检查 - 确保所有自动化检查通过
  2. 响应审查评论 - 及时处理反馈
  3. 保持 PR 最新 - 如果出现冲突，合并 master
  4. 重新运行相关验证 - 根据审查反馈进行更改后。对于代码更改，重新运行 cargo fmt/cargo clippy（以及其他相关检查）；对于仅文档更改，则不需要。

最佳实践

  • 保持 PR 聚焦 - 尽可能每个 PR 只包含一个逻辑更改
  • 编写清晰的提交消息 - 解释什么和为什么，而不仅仅是做了什么
  • 先自我审查 - 在请求审查之前审查你自己的差异
  • 更新测试 - 确保测试覆盖反映你的更改
  • 记录重大更改 - 指出任何 API 更改或破坏性修改
  • 使用功能标志 - 在适当时将风险更改置于功能标志之后（请参阅 add-feature-flag 技能）